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§
Sourcefn view_any(user: &U) -> bool
fn view_any(user: &U) -> bool
Whether user may list resources of this type (Laravel’s viewAny).
Sourcefn view(&self, user: &U) -> bool
fn view(&self, user: &U) -> bool
Whether user may view this specific resource (Laravel’s view).
Sourcefn create(user: &U) -> bool
fn create(user: &U) -> bool
Whether user may create a resource of this type (Laravel’s create).
Provided Methods§
Policy::view_any, converted straight to a 403 on failure.
Policy::view, converted straight to a 403 on failure.
Policy::create, converted straight to a 403 on failure.
Policy::update, converted straight to a 403 on failure.
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".