Trait IDynamicAuthorizer 

pub trait IDynamicAuthorizer: Send + Sync {
    // Required method
    fn authorize<'life0, 'life1, 'life2, 'life3, 'async_trait>(
        &'life0 self,
        claims: &'life1 dyn IClaims,
        route_pattern: &'life2 str,
        method: &'life3 str,
    ) -> Pin<Box<dyn Future<Output = Result<(), Error>> + Send + 'async_trait>>
       where 'life0: 'async_trait,
             'life1: 'async_trait,
             'life2: 'async_trait,
             'life3: 'async_trait,
             Self: 'async_trait;

    // Provided methods
    fn authorize_with_rules<'life0, 'life1, 'life2, 'life3, 'life4, 'life5, 'async_trait>(
        &'life0 self,
        claims: &'life1 dyn IClaims,
        route_pattern: &'life2 str,
        method: &'life3 str,
        _declared: &'life4 DeclaredRules<'life5>,
    ) -> Pin<Box<dyn Future<Output = Result<(), Error>> + Send + 'async_trait>>
       where 'life0: 'async_trait,
             'life1: 'async_trait,
             'life2: 'async_trait,
             'life3: 'async_trait,
             'life4: 'async_trait,
             'life5: 'async_trait,
             Self: 'async_trait { ... }
    fn authorize_with_declared_rules<'life0, 'life1, 'life2, 'life3, 'async_trait>(
        &'life0 self,
        claims: &'life1 dyn IClaims,
        route_pattern: &'life2 str,
        method: &'life3 str,
        declared: &'static [AuthorizeRule],
    ) -> Pin<Box<dyn Future<Output = Result<(), Error>> + Send + 'async_trait>>
       where 'life0: 'async_trait,
             'life1: 'async_trait,
             'life2: 'async_trait,
             'life3: 'async_trait,
             Self: 'async_trait { ... }
}

Dynamic authorizer interface — pluggable authorization for protected routes.

Implement this trait and register it in the DI container:

svc.singleton::<dyn IDynamicAuthorizer>(|_| Arc::new(MyAuthorizer::default()))

The framework automatically detects registered IDynamicAuthorizer implementations and invokes them on every route that has #[authorize] — static and #[authorize(dynamic)] alike. If no implementations are registered, authorization is pass-through (no dynamic checks; a dynamic endpoint then only requires an authenticated principal, so the application must enforce its permissions elsewhere or register an authorizer).

Methods

• authorize_with_declared_rules — the primary path since 1.3.0. Receives the endpoint’s &'static [AuthorizeRule] slice directly (zero allocation, the same slice as RouteEntry.authorization). Override this to see which role/permission codes the endpoint declared.
• authorize_with_rules — 1.2.0 signature taking a DeclaredRules view. Kept for source compatibility; the host no longer calls it. Scheduled for removal in 2.0. The default forwards to authorize.
• authorize — receives the user’s claims, matched route pattern, and HTTP method. Kept for source compatibility with 1.1; the default implementation of both methods above ends up here, so an implementation that only overrides authorize keeps working unchanged.

Dynamic endpoints

On a route declared #[authorize(dynamic)] the static gate stops at “authenticated” (no claims → 401) and the declaration in RouteEntry.authorization is passed to the authorizers instead of being evaluated against claims.permissions(). That makes an authorizer backed by the database (“DB is the source of truth”) authoritative per request, without shipping a permission snapshot in the token.

Required Methods

fn authorize<'life0, 'life1, 'life2, 'life3, 'async_trait>( &'life0 self, claims: &'life1 dyn IClaims, route_pattern: &'life2 str, method: &'life3 str, ) -> Pin<Box<dyn Future<Output = Result<(), Error>> + Send + 'async_trait>>

where 'life0: 'async_trait, 'life1: 'async_trait, 'life2: 'async_trait, 'life3: 'async_trait, Self: 'async_trait,

Validate whether the authenticated user can access the resource.

Provided Methods

fn authorize_with_rules<'life0, 'life1, 'life2, 'life3, 'life4, 'life5, 'async_trait>( &'life0 self, claims: &'life1 dyn IClaims, route_pattern: &'life2 str, method: &'life3 str, _declared: &'life4 DeclaredRules<'life5>, ) -> Pin<Box<dyn Future<Output = Result<(), Error>> + Send + 'async_trait>>

where 'life0: 'async_trait, 'life1: 'async_trait, 'life2: 'async_trait, 'life3: 'async_trait, 'life4: 'async_trait, 'life5: 'async_trait, Self: 'async_trait,

Validate access with the endpoint’s declared role / permission codes.

Legacy since 1.3.0 — the host now calls IDynamicAuthorizer::authorize_with_declared_rules, which passes the raw slice. This method is kept for source compatibility (existing implementations that override it still receive the rules through the new method’s default forwarding) and is scheduled for removal in 2.0.

A default implementation forwarding to authorize keeps 1.1 implementations wire-compatible.

fn authorize_with_declared_rules<'life0, 'life1, 'life2, 'life3, 'async_trait>( &'life0 self, claims: &'life1 dyn IClaims, route_pattern: &'life2 str, method: &'life3 str, declared: &'static [AuthorizeRule], ) -> Pin<Box<dyn Future<Output = Result<(), Error>> + Send + 'async_trait>>

where 'life0: 'async_trait, 'life1: 'async_trait, 'life2: 'async_trait, 'life3: 'async_trait, Self: 'async_trait,

Validate access with the endpoint’s declared #[authorize] rules.

The zero-allocation primary path (new in 1.3.0): declared is the endpoint’s RouteEntry.authorization slice itself, borrowed for the whole process. Every item is one #[authorize] attribute and all of them must hold (AND); inside one item the role and permission lists are any-of. On a #[authorize(dynamic)] endpoint the static gate does not evaluate these rules — this method decides.

The default forwards to IDynamicAuthorizer::authorize_with_rules (which forwards to IDynamicAuthorizer::authorize), so an existing implementation that overrides either legacy method works unchanged.

Dyn Compatibility

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors