Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
arium-authz
Per-resource, relationship-based authorization — standalone.
This is arium's second authorization axis, extracted so it can be used independently of the arium auth engine. Global RBAC (flat permission tokens) answers "what is this user across the whole app?"; this crate answers "what is this user with respect to this one resource?" — the defining need of collaborative apps (a board, a document, a project a user owns/edits/views).
authz— the enforcement boundary: theResourceRolelattice,ResourceAuthority(the one trait an app implements over its own storage), andrequire_resource(fresh, per-request, default-deny). Always available.membership— the lifecycle layer:MembershipStore(a supertrait ofResourceAuthority) and the invariant-bearing compositesgrant_membership/revoke_membership/transfer_ownership. Behind the default-onlifecyclefeature; turning it off drops the sqlx-transaction surface for pure-enforcement embedders.
arium stores no resource memberships — the app owns that storage. The
global↔resource composition bridge (require_resource_or_permission) lives
in the arium engine crate, where both axes are present.
Installation
Pick exactly one backend (sqlite or postgres); it forwards down to
arium-pool so the whole tree agrees on one Pool type:
[]
= { = "0.1", = ["sqlite"] }
Pure-enforcement embedders that don't want the membership lifecycle (and its
sqlx-transaction surface) can drop the default lifecycle feature:
[]
= { = "0.1", = false }
Full API reference on docs.rs. Key items: ResourceRole, ResourceAuthority, require_resource, MembershipStore, and the grant_membership / revoke_membership / transfer_ownership composites.
License
Licensed under either of:
at your option.