Weave Code
Rbac Laravel Package
binary-cats/rbac
Binary Cats RBAC is a Laravel role-based access control package for managing roles, permissions, and guards. It provides middleware, Blade directives, caching, and a fluent API to secure routes, controllers, and UI elements with minimal configuration.
RBAC extension to spatie/laravel-permissions
Frequently asked questions about Rbac
- What is binary-cats/rbac and how does it relate to spatie/laravel-permission?
- Binary Cats RBAC is a Laravel role-based access control package that extends spatie/laravel-permission rather than replacing it. It layers a role, permission and guard model on top of Spatie's tables and Eloquent models, then adds middleware, Blade directives, permission caching and a fluent API for defining checks. The practical benefit is fewer manual wiring steps: you get an opinionated, Laravel-native surface for securing routes, controllers and UI elements with minimal configuration. If you already run Spatie, it is best treated as a structured RBAC layer on the same foundation, not a second parallel authorization system.
- How do I install and configure binary-cats/rbac in a Laravel application?
- Install with Composer, then publish the package config and migrations and review the generated schema before running migrate. Next, seed your role and permission matrix, register the middleware aliases, and attach the route middleware to the groups you want to protect. From there, replace ad-hoc authorization checks with the package's fluent API and Gate calls. Release 2.4.0 also ships Boost guidelines (AGENTS.md style context files) to help AI-assisted tooling and new developers get the naming conventions right on the first pass.
- Which Laravel and PHP versions does binary-cats/rbac support?
- Version support is defined by the Composer constraints in the package's composer.json, so check those against your application's Laravel and PHP versions before committing. The 2.4.x line is the current release line, and 2.4.0 is a developer-experience and documentation release with no API, deprecation or schema changes. The overview does not publish an explicit support window, so confirm the maintenance commitment on the repository before you standardize on a minor version.
- How does permission caching work and how do I invalidate the cache?
- The package provides a permission caching layer so role and permission lookups do not hit the database on every check. The important question is invalidation: whenever a role or permission is created, updated, deleted or reassigned, the affected cache entries must be flushed, and you should also clear the cache as part of your deploy process. A stale permission cache on an authorization path can mean either privilege escalation or hard-to-diagnose denials. Verify the invalidation hooks against your own mutation points, including admin panels and seeders that write roles outside the package API.
- How do I protect routes and controllers with RBAC middleware?
- Register the package middleware aliases in your HTTP kernel or bootstrap file, then attach them to route groups, individual routes or controller constructors. Middleware must run after authentication so a user is already resolved when the role or permission check happens, otherwise you get confusing denials or bypasses. Start with low-blast-radius route groups when rolling out and expand once behavior is verified. For anything more expressive than a simple role or permission gate, prefer Laravel Gates and Policies over stacking middleware.
- How do I use Blade directives to hide UI elements a user cannot access?
- The package ships Blade directives that wrap role and permission checks so you can conditionally render navigation items, buttons and admin panels. Use them for presentation only: hiding a button is not authorization, so the corresponding route or controller action must still enforce the same check server-side. Where directives do not cover your case, fall back to Laravel's native @can with a Gate or Policy. Keep the directive names consistent across views so a later audit can grep for them.
- Does binary-cats/rbac support multiple guards, teams, or tenant-scoped roles?
- Guards are a first-class concept in the package, so you can define and check permissions per guard for separate user types or portals. Whether roles are global per user or scoped to a team or tenant is the key question to verify before adoption, because it determines whether the role model fits a multi-tenant application. If you need per-tenant role assignment, confirm the schema and API support it or plan an extension. Test the scoping behavior explicitly, since a global role model in a tenant app is a cross-tenant data leak waiting to happen.
- How do I migrate from a users.role column or an existing Spatie setup?
- Backfill roles and permissions from your existing column or tables using a one-time seeder or artisan command, then run a shadow-read period where the legacy checks remain authoritative and package checks are logged for divergence. Cut over route group by route group, starting with the lowest-risk areas, and only remove legacy checks and columns once divergence has been zero for a full release cycle. Pin the package version in a non-production environment first and review the published migrations before applying them. If you are already on Spatie, the migration is mostly about mapping your existing roles onto the package's role and permission model rather than moving data.
- How do I test role and permission checks in my Laravel test suite?
- Seed a minimal role and permission matrix in your test setup, use actingAs to authenticate users with each role, and assert both the happy path and the expected 403 or 302 for unauthorized access. Add tests for middleware ordering and for cache invalidation: change a role, then assert the next request reflects the change without a manual cache clear. Cover the Blade output as well, so a hidden button and a blocked route stay in sync. These tests are cheap to write and they are your main defense against silent privilege escalation after a refactor.
- What are the maintenance and production risks of adopting binary-cats/rbac?
- Release 2.4.0 is low risk by construction: no API changes, no deprecations, no schema changes. The material risks are package-level rather than release-level, chiefly the small maintainer team behind Binary Cats, where bus factor and release cadence are the long-term concerns. Authorization is a security-critical path, so pin the version, monitor the repository, and do not run competing role implementations side by side. Treat the Boost guidelines as a convenience tied to a specific version, and re-check them whenever you upgrade the package minor.
Weaver
How can I help you explore Laravel packages today?