Expand description
Authorization aspects.
This module provides two complementary authorization aspects:
-
AuthorizationAspect— role-based access control (RBAC). Given the set of roles the caller holds, admit or deny based on a required-role policy. The classical AspectJ / Spring Security shape. -
AllowlistAspect— identity-based allowlisting. Given an identity string (user ID, phone number, email, public key, etc.), admit if it matches a configured set, with optional wildcard and normalization hooks. This is the shape that recurs across messaging-channel integrations: each channel has its own per-channel allowlist of who is permitted to talk to the bot. The ICSE 2027 evaluation migrates the zeroclaw codebase from 25 hand-rolled per-channel checks to a single sharedAllowlistAspectconfigured per channel.
Structs§
- Allowlist
Aspect - Identity-based allowlist aspect.
- Allowlist
Call - Per-call context bound to the most recent guarded join point. Set by
the host before
proceed()is invoked; cleared byrelease. - Authorization
Aspect - Role-based access control aspect.
Enums§
- Auth
Mode - Authorization mode.
- Match
Policy - Borrowed matching policy for the stateless
is_allowed_inentry point.
Functions§
- is_
allowed_ in - Stateless allowlist check: returns
truewhenidentityis admitted byentriesunderpolicy. Holds no state — the caller passes the entries (typically resolved from a canonical config source per call), so this satisfies single-source-of-truth invariants that forbid caching the allowlist in a long-lived field.