Weave Code
Laravel Yes Authority Laravel Package
livelyworks/laravel-yes-authority
LivelyWorks Yes Authority is a Laravel package for role- and permission-based access control. It helps define roles, assign permissions, and protect routes and views with simple authorization checks.
Laravel Routes Authorization Library
Frequently asked questions about Laravel Yes Authority
- How do I install livelyworks/laravel-yes-authority in a Laravel app?
- Run composer require livelyworks/laravel-yes-authority, then publish the package config with vendor:publish and review the route-access map it ships with. Register the middleware alias (auto-discovery is expected on modern Laravel, but verify it) and attach the middleware to the route groups you want to protect. There are no migrations, no schema changes, and no external services, so a pilot group can be running in under a day. The real effort is inventorying your named routes and building an accurate access map, which is ongoing governance rather than a one-time setup step.
- Does laravel-yes-authority support Laravel 11 and Laravel 12?
- Unverified. The last release is dated 2023-02-28, which places it in the Laravel 9 and 10 window, and compatibility with Laravel 11 or 12 should not be assumed. Laravel 11 introduced a slimmed skeleton and moved middleware registration into bootstrap/app.php, which is exactly the kind of change that affects a middleware-centric package. Check the composer.json illuminate/* and PHP constraints, then run a smoke test on your target version before committing to it.
- How is YesAuthority different from Laravel Gates and Policies?
- Gates and Policies answer whether a user can perform a specific ability on a specific resource, while YesAuthority answers whether a user can reach a named route. That makes it a thin, opinionated layer that sits alongside Laravel's native authorization rather than on top of it. For large, flat route surfaces such as admin panels and back-office screens, the route name is a natural permission boundary and this avoids writing a policy per screen. It is a poor fit for fine-grained, resource-scoped or multi-tenant row-level rules.
- How do I define roles and map route names to permissions in the config?
- Authorization is declared in a config-level map that pairs route names with the roles or permissions allowed to reach them, including wildcard patterns for route-name matching. You populate that map and then protect route groups with the package middleware, with helper and Blade directive checks available for views. Because permissions are keyed on developer-controlled route name strings, renaming a route silently decouples it from its permission entry. Treat the map as a maintained artifact and review it whenever routes change.
- Does YesAuthority deny by default when a route is not in the access map?
- You must confirm this explicitly rather than infer it, because the failure direction depends entirely on the package's unmatched-route behavior. Whether an unmapped route is denied or allowed determines whether a stale config becomes a privilege-escalation path or a broken screen. Check the source and any test suite specifically for coverage of the deny paths. If the behavior is incidental rather than tested, add your own tests around it before relying on it in production.
- How does wildcard matching work when multiple route name patterns match?
- YesAuthority performs wildcard matching over route names, which is what lets you grant access to a group of screens with a single entry. When multiple patterns match the same route, the precedence rule determines the outcome, so verify that it is deterministic and documented. If precedence is ambiguous or undocumented, keep your map free of overlapping patterns. This is a security-relevant detail worth a dedicated test in your own suite.
- How do I check authority in Blade views or controllers instead of middleware?
- The package exposes a helper and a Blade directive so you can conditionally render navigation links and UI elements based on whether the current user may reach a route. Use middleware for the actual route-level gate, and reserve the helper and directive for presentation. Do not treat a hidden menu item as an access control, since the underlying route still needs its own protection. Keep resource-level checks in policies and use YesAuthority only for the coarse may-this-user-enter-this-screen decision.
- How does it resolve the authenticated user across multiple guards like Sanctum?
- This is an open question for the package and should be confirmed before scoping it to any surface that mixes session and token authentication. It is designed around server-rendered Laravel monoliths with session auth, and how it resolves the user across multiple guards such as web and Sanctum is not established by the overview. Stateless API and token stacks are a weaker fit. Test guard resolution explicitly if your app supports more than one guard.
- Can I use YesAuthority for API routes and resource-scoped permissions?
- Not well. It is a poor fit for APIs with fine-grained, resource-scoped authorization, for multi-tenant row-level rules, or for anything where permissions must be data-driven at runtime. Because the permission boundary is the route name, it cannot express rules like a user may edit only their own record. Keep that logic in Gates and Policies and use YesAuthority only for the coarse route-entry gate, if you use it on JSON endpoints at all.
- Is livelyworks/laravel-yes-authority actively maintained, and can I fork it?
- Activity is low: seven stars, zero dependents, and a last release in February 2023, which means effectively no adversarial scrutiny on security-critical authorization code. Budget for an external review of the deny paths, wildcard precedence, and guard handling rather than trusting the MIT license alone. Because the surface is small, a clean fork under your own namespace published to a private registry is realistic. That is often the right move if you adopt it and need to guarantee Laravel 11 or 12 compatibility and PHP 8.3 or 8.4 support.
Weaver
How can I help you explore Laravel packages today?