Roles, per-route permissions, menus and an optional admin UI — every authorization check is a bitwise AND, not a database query.
Most permission packages store one database row per role × permission × resource. That scales into a maintenance problem. A bitwise permission collapses any combination of capabilities into a single integer, checked with CPU-level math.
// one row per capability, per role, per resource
DB::table('role_has_permissions')
->where('role_id', $role->id)
->where('resource', 'leads')
->whereIn('permission', ['view','create','update'])
->count() === 3;
// one integer, resolved once per request
$access = $user->getAccess(); // 13
$access & $bits['create'] === $bits['create']; // true
The bitwise core is the foundation. On top of it: route protection, role cloning, self-managing menus, and an optional UI to run the whole thing without touching a migration.
Combine and compare permissions with plain integer math — combine(), decode(), has().
Protect named routes with a wildcard convention: leads.*, deals.*.
A navigation tree with role visibility and automatic parent/child propagation.
The configured super admin role gets full access without ever touching the database.
RoleCloneService clones a base role per user, so individual permissions diverge safely.
Manage roles, permissions, routes, accesses and menus from /bwp/* out of the box.
bwp:install and bwp:sync-routes get a project wired up in minutes.
Bits, base permissions, roles, routes and menus all live in one published config file.
use HenryHt\BitwisePermission\Traits\HasPermissionsTrait;
class User extends Authenticatable
{
use HasPermissionsTrait;
}
Route::middleware('bwp.permission:create')->group(function () {
Route::post('/leads', [LeadController::class, 'store'])->name('leads.store');
});
@if(auth()->user()->canCreate())
<a href="{{ route('leads.create') }}">New lead</a>
@endif
| Guide | Covers |
|---|---|
| Installation | Requirements, install command, manual setup, wiring the User model |
| Configuration | Bits, base permissions, super admin, table prefix, menus |
| Middleware | Protecting routes and the view prerequisite rule |
| Roles | Base roles, per-user roles, RoleCloneService |
| Permissions | Checking, setting and combining permissions at runtime |
| Menus | Building navigation trees with role-based visibility |
| Examples | End-to-end flows: user creation, custom bits, Livewire |
| Upgrading | Version-to-version upgrade notes |