Authorizable Contract

Purpose and Scope

This document covers the Authorizable contract and its implementation trait, which provide authorization checking capabilities to any entity (typically user models) in the authentication system. The Authorizable contract defines the interface for checking permissions, while the accompanying trait provides the implementation.

For information about authorization policies and gate definitions, see Policies and Abilities. For the underlying Gate system that powers authorization checks, see Gate Contract. For the complementary Authenticatable contract used for authentication, see Authenticatable Contract.

---

Interface Definition

The Authorizable contract is defined in src/Contracts/Authorizable.php7-13 and specifies a single method that entities must implement to support authorization checks:

This interface is intentionally minimal, requiring only the core can() method. The implementation is responsible for delegating to the Gate system to perform the actual authorization logic.

Sources: src/Contracts/Authorizable.php1-14

---

Trait Implementation

The Authorizable trait in src/Access/Authorizable.php provides a complete implementation of the contract, adding several convenience methods beyond the required interface:

Authorizable Trait Structure

Sources: src/Contracts/Authorizable.php1-14 src/Access/Authorizable.php1-44

---

Method Reference

can()

Determines if the entity has the given ability or abilities. This is the core authorization method defined by the contract.

Signature: src/Access/Authorizable.php15

Parameters:

Parameter	Type	Description
$abilities	iterable|string	Single ability name or array of abilities to check
$arguments	mixed	Optional arguments passed to the gate/policy (typically model instances)

Returns: bool - true if all specified abilities are granted, false otherwise

Implementation: src/Access/Authorizable.php17

• Retrieves the Gate instance from the application container
• Calls forUser($this) to scope the gate to the current entity
• Delegates to Gate::check() for the actual authorization logic

canAny()

Determines if the entity has at least one of the given abilities. Useful for OR-based permission checks.

Signature: src/Access/Authorizable.php23

Parameters: Same as can()

Returns: bool - true if any of the specified abilities are granted, false if all are denied

Implementation: src/Access/Authorizable.php25

• Delegates to Gate::any() instead of Gate::check()
• Returns true on the first allowed ability

cant() / cannot()

Both methods provide the inverse of can(), determining if the entity does NOT have the given abilities.

Signatures: src/Access/Authorizable.php31-39

Parameters: Same as can()

Returns: bool - true if abilities are denied, false if granted

Implementation:

• cant() simply negates the result of can() src/Access/Authorizable.php33
• cannot() is an alias for cant() src/Access/Authorizable.php41

Sources: src/Access/Authorizable.php1-44

---

Authorization Flow

The following diagram illustrates how authorization checks flow from an entity through the trait to the Gate system:

Authorization Delegation Flow

Key Points:

• The trait resolves the Gate from the container on each call src/Access/Authorizable.php17
• forUser($this) scopes the gate to the current entity src/Access/Authorizable.php17
• The Gate handles all policy resolution and ability evaluation
• Results are not cached; each call performs a fresh check

Sources: src/Access/Authorizable.php15-18 src/Contracts/Gate.php

---

Usage Patterns

Basic Model Integration

To enable authorization checks on a model, implement the Authorizable contract and use the trait:

Once integrated, authorization checks can be performed directly on model instances:

Sources: src/Access/Authorizable.php1-44

---

Method Comparison Table

Method	Purpose	Logic	Use Case
can()	Check if user has abilities	AND - all must pass	Verify user has all required permissions
canAny()	Check if user has any ability	OR - at least one must pass	Verify user has at least one permission from a set
cant()	Check if user lacks abilities	NOT - inverse of can()	Verify user does NOT have permission
cannot()	Alias for cant()	NOT - inverse of can()	Semantic alternative to cant()

Sources: src/Access/Authorizable.php15-42

---

Relationship to Other Components

Integration Points

Key Relationships:

• Authorizable Contract - Defines the required interface src/Contracts/Authorizable.php7-13
• Authorizable Trait - Provides default implementation src/Access/Authorizable.php10-43
• Gate - Performs actual authorization logic via policies and callbacks src/Contracts/Gate.php
• ApplicationContext - Resolves Gate instance from container src/Access/Authorizable.php17

Sources: src/Access/Authorizable.php1-44 src/Contracts/Authorizable.php1-14

---

Comparison with AuthorizesRequests

The AuthorizesRequests trait src/Access/AuthorizesRequests.php serves a different purpose and should not be confused with Authorizable:

Feature	Authorizable	AuthorizesRequests
Purpose	Add authorization methods to entities	Add authorization methods to controllers
Target	User models and authenticatable entities	Controller classes
Methods	can(), canAny(), cant(), cannot()	authorize(), authorizeForUser()
Behavior	Returns boolean, non-throwing	Throws AuthorizationException on denial
Use Case	Check permissions in models/services	Enforce permissions in HTTP handlers

Sources: src/Access/Authorizable.php1-44 src/Access/AuthorizesRequests.php1-77

---

Implementation Details

Container Resolution

The trait uses ApplicationContext::getContainer()->get(Gate::class) on every method call src/Access/Authorizable.php17 which means:

• No gate instance is cached in the entity
• The gate is resolved fresh on each authorization check
• This allows the gate to reflect any runtime changes to policies or callbacks
• In Hyperf's coroutine environment, this ensures proper context isolation

User Scoping

The forUser($this) call src/Access/Authorizable.php17 is critical:

• It creates a gate instance scoped to the current entity
• This allows policies to receive the correct user for authorization checks
• Without this scoping, the gate would use the currently authenticated user from context
• This enables authorization checks for users other than the authenticated user

Arguments Forwarding

The $arguments parameter is passed through to the gate unchanged src/Access/Authorizable.php17:

• Typically contains model instances that policies need to evaluate
• Can be a single value or an array of values
• Policies receive these as method parameters after the user

Sources: src/Access/Authorizable.php15-18

---

Common Patterns

Guest User Checks

The trait can be used on any entity, including guest users:

The Gate system handles guest users appropriately, typically denying most actions unless explicitly allowed.

Multi-Ability Validation

When checking multiple abilities with can(), all must pass:

Conditional Logic

The boolean return values integrate naturally with conditional statements:

Sources: src/Access/Authorizable.php1-44

---

Summary

The Authorizable contract provides a clean, fluent interface for authorization checks on entities. Its trait implementation delegates all authorization logic to the Gate system while providing convenient helper methods for common authorization patterns.

Key Takeaways:

• Interface: Single can() method required by contract src/Contracts/Authorizable.php12
• Trait: Provides can(), canAny(), cant(), cannot() implementations src/Access/Authorizable.php10-43
• Delegation: All authorization logic delegated to Gate system src/Access/Authorizable.php17
• Scoping: Gate is scoped to the entity via forUser() src/Access/Authorizable.php17
• Integration: Simple to add to any entity via trait usage

Sources: src/Contracts/Authorizable.php1-14 src/Access/Authorizable.php1-44