- Does this package work with Laravel 10+ or only older versions?
- The package was last updated in 2020 and relies on outdated dependencies like `laravel/ui:^2|^3`, which may conflict with Laravel 10+. Test thoroughly in a staging environment, or consider forking to update dependencies. It *should* work with Laravel’s core middleware system, but compatibility isn’t guaranteed.
- How do I restrict access to specific routes or controllers?
- Use the `restricted` middleware in your `Kernel.php` or apply it directly to route groups. For example: `Route::middleware(['auth', 'restricted'])->group(function () { ... })`. You can also define restricted areas in the package’s config (if published) to centralize rules.
- Can I use this for IP-based restrictions (e.g., blocking all traffic except my office IP)?
- Yes, the package supports IP-based restrictions out of the box. Configure allowed IPs in the middleware or via the config file (if published). It will block all other requests with a clear response, making it ideal for staging or maintenance locks.
- Will this work with Laravel Breeze/Jetstream or other modern auth systems?
- The package integrates with Laravel’s native auth system, so it *should* work with Breeze/Jetstream. However, since it depends on `laravel/ui`, there’s a risk of conflicts. Test in isolation first, and ensure your auth middleware is properly sequenced in `Kernel.php`.
- How do I handle frontend restrictions (e.g., disabling buttons when restricted mode is active)?
- The package only enforces backend restrictions. You’ll need to manually implement frontend checks—either via Blade directives (e.g., `@if(!restricted()) ... @endif`) or JavaScript (e.g., checking a session flag or API response). No built-in UI enforcement exists.
- Can I combine this with Laravel Policies or Gates for granular permissions?
- Yes, the package is middleware-based, so you can layer it with Policies or Gates. For example, use `restricted` middleware for broad blocks (e.g., environments) and Policies for fine-grained checks (e.g., user roles). Just ensure the middleware runs *before* your auth checks in `Kernel.php`.
- Does this package add significant performance overhead?
- No, the package is lightweight and only adds minimal middleware logic. The overhead is negligible unless you’re applying it to thousands of routes. Benchmark in your staging environment to confirm, but expect near-zero impact compared to Laravel’s built-in middleware.
- Are there alternatives to this package that are actively maintained?
- Yes, consider `spatie/laravel-permission` for role-based access or Laravel’s built-in Policies/Gates + custom middleware for fine-grained control. These are more actively maintained and integrate better with modern Laravel. This package is best for simple, temporary restrictions.
- How do I configure environment-specific restrictions (e.g., read-only mode in staging)?
- Use the package’s config (publish it with `php artisan vendor:publish`) to define environment-based rules. For example, set `restricted_environments = ['staging']` to auto-enable restrictions in staging. You can also dynamically check `app()->environment()` in the middleware logic.
- What happens if a restricted request is made? Does it return a 403 or a custom message?
- By default, restricted requests return a 403 Forbidden response. You can customize this in the middleware to return a JSON error, redirect, or even a Blade view. Check the middleware source to override the `handle()` method for your preferred response.