Skip to main content

Policy

Trait Policy 

Source
pub trait Policy<U: Authenticatable> {
    // Required methods
    fn view_any(user: &U) -> bool;
    fn view(&self, user: &U) -> bool;
    fn create(user: &U) -> bool;
    fn update(&self, user: &U) -> bool;
    fn delete(&self, user: &U) -> bool;

    // Provided methods
    fn authorize_view_any(user: &U) -> Result<(), AppError> { ... }
    fn authorize_view(&self, user: &U) -> Result<(), AppError> { ... }
    fn authorize_create(user: &U) -> Result<(), AppError> { ... }
    fn authorize_update(&self, user: &U) -> Result<(), AppError> { ... }
    fn authorize_delete(&self, user: &U) -> Result<(), AppError> { ... }
}
Expand description

A per-resource authorization policy (Laravel’s Policy classes), hand- implemented once per model - the same shape as crate::Authenticatable on User: a small trait the app implements directly, not macro-generated or auto-discovered, so a typo in an ability name is a compile error rather than a silently-always-false runtime lookup.

view_any/create are class-level abilities (no specific row exists yet - Laravel checks these against Post::class, not an instance) and take no &self; view/update/delete are instance-level and do. Rust traits allow mixing associated functions and methods freely, so this stays one trait rather than two.

Deliberately excludes Laravel’s restore/forceDelete - this framework has no soft-delete concept anywhere in larust-orm, so those two abilities would have nothing to gate.

All 5 abilities are required, with no default false body: a trait- level default would reintroduce exactly the “silent gap instead of compile error” failure mode crate::authorize’s own doc comment already treats as this framework’s core selling point over Laravel’s Gate::define. Forgetting to decide an ability is a compile error, not a silently-safe (or silently-unsafe) default.

Each ability has a matching authorize_* default method that converts its bool into a Result<(), AppError> via crate::authorize - sugar so a caller writes post.authorize_update(&user)? instead of authorize(post.update(&user))?.

ⓘ
impl larust_support::auth::Policy<User> for Post {
    fn view_any(_user: &User) -> bool { true }
    fn view(&self, _user: &User) -> bool { true }
    fn create(_user: &User) -> bool { true }
    fn update(&self, user: &User) -> bool { self.user_id == user.id }
    fn delete(&self, user: &User) -> bool { self.user_id == user.id }
}

Required Methods§

Source

fn view_any(user: &U) -> bool

Whether user may list resources of this type (Laravel’s viewAny).

Source

fn view(&self, user: &U) -> bool

Whether user may view this specific resource (Laravel’s view).

Source

fn create(user: &U) -> bool

Whether user may create a resource of this type (Laravel’s create).

Source

fn update(&self, user: &U) -> bool

Whether user may update this specific resource (Laravel’s update).

Source

fn delete(&self, user: &U) -> bool

Whether user may delete this specific resource (Laravel’s delete).

Provided Methods§

Source

fn authorize_view_any(user: &U) -> Result<(), AppError>

Policy::view_any, converted straight to a 403 on failure.

Source

fn authorize_view(&self, user: &U) -> Result<(), AppError>

Policy::view, converted straight to a 403 on failure.

Source

fn authorize_create(user: &U) -> Result<(), AppError>

Policy::create, converted straight to a 403 on failure.

Source

fn authorize_update(&self, user: &U) -> Result<(), AppError>

Policy::update, converted straight to a 403 on failure.

Source

fn authorize_delete(&self, user: &U) -> Result<(), AppError>

Policy::delete, converted straight to a 403 on failure.

Dyn Compatibility§

This trait is not dyn compatible.

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

Implementors§