Download the PHP package afurgeri/laravel-rbac without Composer

Laravel RBAC

Roles, permissions, role assignment, and permission middleware for Laravel applications. The package depends on afurgeri/laravel-crud for reusable CRUD definitions.

Scope

This package provides the reusable RBAC core:

• SQL and MongoDB role and permission models;
• HasRoles and HasPermissions integration contracts;
• permission middleware;
• configurable RBAC tables and user model;
• migrations and permission seeders;
• role authorization through Laravel policies;
• optional CRUD integration for the Role model.

Resource-specific user CRUD, Inertia controllers, routes, navigation, and Vue pages belong in the consuming application.

Installation

Both the RBAC and CRUD service providers are registered through Laravel package discovery.

After installing both packages, generate the application integration with:

rbac:install generates the user/role CRUD definitions, controllers, policy, routes, and Inertia/Vue pages. It requires the generic CRUD frontend files from crud:install and reports the required User model integration without modifying the model automatically.

For MongoDB, install the official driver in the consuming application and select the MongoDB integration stubs:

The installer generates explicit Role and Permission model configuration for the selected connector. It does not generate or modify the application's authenticatable User model.

If Packagist is temporarily unavailable, add the GitHub repositories as temporary VCS sources:

Then require the tagged versions:

Full MongoDB application

Selecting --database=mongodb configures the RBAC role and permission models, but it cannot replace the application's User model automatically. For a fully MongoDB-backed application, the authenticatable model must use the MongoDB authentication base class and the RBAC trait:

The essential changes compared with the default Laravel model are:

• Replace Illuminate\Foundation\Auth\User with MongoDB\Laravel\Auth\User.
• Keep HasRoles and HasPermissions on the same model used by the configured auth provider.
• Set the mongodb connection and the users collection/table.
• Store name, email, password, remember_token, and any fields required by the application's authentication features in the user document.
• Keep the password hashed and hidden. Do not store a plain-text password.
• Add role_ids as an array of role document IDs. The package's MongoDB relationship reads this field from the user document.

The application must also point both Laravel authentication and RBAC to this model:

If the application uses Fortify, keep its normal provider and actions, but verify every action that creates or updates users uses the MongoDB model. Password reset storage also needs the MongoDB integration provider; the standard SQL password-reset migration is not enough for a full MongoDB setup. Passkeys, two-factor authentication, sessions, and API tokens may require their own MongoDB-compatible storage configuration.

User model integration

The application's authenticatable model must use HasRoles and implement HasPermissions:

Configure the application user model in config/rbac.php. The installer writes the explicit role and permission classes for its selected connector, but leaves models.user unset because it must point to the consuming application's authenticatable model:

Publish the configuration and migrations when they need to be customized:

Permissions

Use hasPermission() in application authorization logic:

Protect routes with the registered permission middleware:

Application-specific permission constants should be declared by the application or a dependent package. The bundled RbacPermissions list contains the permissions used by the companion scaffold.

CRUD integration

Role implements the CRUD definition bridge and can be used with CrudIndexManager, CrudSchemaManager, and CrudMutationManager from afurgeri/laravel-crud.

The package does not provide user CRUD because user fields, password handling, policies, routes, and frontend pages differ between applications.

MongoDB behavior

MongoDB uses MongoRole and MongoPermission with permission_ids, role_ids, and user role_ids arrays instead of SQL pivot tables. The package migration owns only the roles and permissions collections; the consuming application owns its users collection and its indexes.

The relationship is represented in both directions:

Use the relationship methods rather than writing these arrays manually:

The MongoDB installer sets storage to mongodb and configures MongoRole::class and MongoPermission::class. Configure the application's MongoDB User model, set models.user, and create an index on users.role_ids when role-based lookups need to scale. The SQL installer instead configures Role::class and Permission::class and uses the configured pivot tables.

The application owns the users collection and should create its indexes explicitly. At minimum, consider unique email and a multikey index on role_ids:

MongoDB document IDs are commonly ObjectId values. Treat route and frontend IDs as strings at the application boundary, while passing the original model keys to Eloquent relationships. Do not mix SQL pivot migrations with the MongoDB RBAC setup.

MongoDB integration tests are separate from the default SQL suite. From the package repository, install the optional test dependency, enable the MongoDB PHP extension, start MongoDB, and run:

Service provider behavior

The provider automatically:

• merges the default rbac configuration;
• loads RBAC migrations and JSON translations;
• registers the permission middleware alias;
• exposes configuration and migration publish tags.

It does not register web routes or Inertia pages.