agent

middleware/webauth.go

@@ -42,11 +42,23 @@ import (
 //
 // ── What this does NOT yet do ───────────────────────────────────────────────
 //
-// It verifies what a request NAMES. It does not yet make handlers derive their
-// scope from the session instead of from the wire, and it does not validate
-// `partnerid`, `customerid` or `appuserid`, which are the other scoping ids
-// some list endpoints accept. Those are the next step, and until they land a
-// handler that scopes on one of them is still trusting the caller.
+// It verifies what a request NAMES: the tenant, and the branch. It does not yet
+// make handlers derive their scope from the session rather than from the wire.
+//
+// It also does not validate `partnerid`, `customerid` or `appuserid`, and that
+// one is not an oversight — it is blocked. A delivery partner serves several
+// merchants at once (`insights.ts` records partner 60 answering with deliveries
+// spanning twelve shops), so scoping a read by partner is a cross-tenant read by
+// design. Refusing the parameter outright would be wrong: `RiderDrawer` and
+// `AssignBar` are merchant screens and both send it legitimately, for a partner
+// assigned to that merchant.
+//
+// Closing it properly needs a check this codebase does not have — "is this
+// partner assigned to this tenant?" — in the shape of `LocationAllowed`, which
+// answers the same question for branches. Until that exists, a handler scoping
+// on one of these three is trusting the caller, and the assistant is kept away
+// from them entirely: no tool accepts any of these as an argument, and the
+// registry refuses to register one that tries.
 
 // WebLocalsKey names where the verified claims are parked for handlers.
 const WebLocalsKey = "webclaims"