Security Laravel Package

Getting Started

Start by installing the package via Composer into a Spiral application (composer require spiral/security). Once installed, register the security module in your app/src/Kernel.php by adding Spiral\Security\SecurityModule to the list of bootloaders. The core entry point is the SecurityInterface, which you’ll inject into controllers or services to perform checks like can($user, $ability, $arguments). The first practical use case is setting up an IdentityInterface implementation (e.g., User entity) and an AuthenticationInterface to resolve the current user—typically via middleware that hydrates a user from a token or session.

Implementation Patterns

• Policy-based authorization: Define policies as classes implementing PolicyInterface (e.g., PostPolicy), then register them with PolicyInterface::class => PostPolicy::class in your service provider. Use $security->can($user, 'update', $post) in controllers or domain services.
• Guard-centric access control: Wrap sensitive operations with guards ($security->denyUnlessCan($user, 'delete', $resource)) to throw AccessDeniedException automatically on failure.
• Pluggable identity providers: Implement custom IdentityInterface for different auth models (e.g., API tokens, OIDC). Integrate with your ORM (e.g., Spiral Database, ORM) in the identity loader—avoiding direct DB access in controllers.
• Testability: Mock SecurityInterface in unit tests to assert access control logic without touching auth providers. Use $this->mock(SecurityInterface::class)->set('can', true) in feature tests.
• Framework integration: Use Spiral’s built-in middleware (Spiral\Security\Middleware\AuthMiddleware) to auto-resolve and attach the current identity to the request context—enabling $security->getUser() to work everywhere.

Gotchas and Tips

• ⚠️ Outdated release (2019): Verify compatibility with modern Spiral versions (v3+). Core concepts remain valid, but API names/methods may differ—review source code and existing Spiral v4 security recipes as fallback.
• ⚠️ Null user handling: Always validate identity existence before checking permissions. can(null, ...) can throw or return false depending on policy design—implement null-safe guards in policies.
• 💡 Policy fallback: Implement a default policy class (via PolicyInterface::class) to catch undefined abilities gracefully instead of crashing.
• 💡 Context-aware guards: Pass contextual data (e.g., ['teamId' => $team->id]) to can() to enable nuanced checks (e.g., “can edit post only in their team”).
• 🔧 Extension point: Replace the default SecurityInterface implementation by binding your own class in a bootloader— useful for adding logging, audit trails, or custom exception handling.