Stage 7 · L31

Explain Casbin, dependency guards and decorator limits

Core · original Session 7

Casbin evaluates a policy model; it does not automatically know the authenticated actor or load record ownership. authorization.py constructs the enforcer from local reviewed model/policy files. The model compares current role, resource and action. Unknown combinations have no allow policy and are denied.

require(resource, action) returns a FastAPI dependency. It resolves current_actor and checks the coarse action before the route's operation. Record ownership remains an explicit SQL predicate. This division is deliberate: the simple Casbin model is role-based, while application scope implements the record attribute rule.

The check-in service also has an explicit actor entry contract for direct trusted callers. Its requires_permission decorator binds arguments using the original signature and uses functools.wraps. The test confirms session/rental_id/actor metadata and verifies a customer call fails before a transaction opens. It is not a generic async decorator: this implementation wraps this synchronous service.

A router-wide dependency and another identical route guard can become duplicated policy work without adding a boundary. Here the HTTP dependency protects the HTTP entry and the service decorator protects direct service calls. Name each purpose. Do not stack decorators blindly, lose function signatures, or pass unresolved Depends objects into an ordinary function.

Policy files are part of the teaching source snapshot. No live policy server, role administrator, organization permission store or production access setting is changed. Reloading an updated local file and reviewing its matrix are separate from creating a safe remote policy-management workflow.

A Casbin ABAC model can receive trusted subject/object attributes and put an ownership condition in its matcher. This snapshot's installed Casbin model intentionally handles role/action only; its SQL predicate performs ownership scope. Passing a caller-built owner attribute to a policy would make the input untrusted. The source's hub-attribute model is a comparison, not an installed Equipment hub resource.

Role inheritance is explicit in the local Casbin g relation. g, operator, customer lets an operator use grants assigned to customer; g, admin, operator extends that chain. The matcher calls g(current_role, policy_role) rather than comparing role strings for equality. The policy retains only the necessary grants and has no wildcard for unknown future actions.

Predict admin read through the chain, then check it with the actual enforcer test. An inherited action grant does not erase record scope: operators still read their own rentals because the SQL predicate is independent. This is an actual role/action inheritance implementation, while the original logistics assigned-hub ABAC model remains a concept comparison.

g, operator, customer
g, admin, operator
p, customer, rental, read
p, operator, rental, check_in
# Matcher uses g(current_role, policy_role).
# SQL ownership still applies after the inherited action grant.

operator inherits customer read; admin inherits operator check-in and customer read. No matching role/resource/action grant means denial. Inheritance grants actions, not records: ordinary ownership remains a separate SQL restriction. The HTTP dependency resolves a current actor; a wraps/signature-preserving synchronous decorator protects direct service calls. Neither invents trusted caller attributes.