Weave Code
Laravel Site Protection Laravel Package
elic-dev/laravel-site-protection
A Laravel package for adding configurable site-wide protection to your application. It uses middleware and Laravel-native configuration to restrict access, shield staging or private sites, and keep unwanted visitors out while authorized users continue smoothly. Simple setup and sensible defaults.
Protect your site with a simple password form
Frequently asked questions about Laravel Site Protection
- How do I install elic-dev/laravel-site-protection in a Laravel app?
- Install it with composer require elic-dev/laravel-site-protection, then publish the package config using the vendor:publish command. Set the shared password through an environment variable or your secret manager rather than committing it to the repository. Finally, attach the package middleware to the web middleware group or a specific route group. The expected integration is a few hours, with no database migrations or schema changes.
- Does laravel-site-protection replace Laravel authentication like Breeze, Jetstream, or Fortify?
- No. It is a single shared password gate backed by a session flag, not a user authentication system. It has no users, roles, per-identity access control, or audit trail. It can coexist with existing auth scaffolding, but you need to plan middleware ordering and route coverage deliberately.
- Which Laravel and PHP versions does this package support?
- The provided overview does not list explicit version constraints, so check the package composer.json before committing. Compare its illuminate and php requirements against your application's version. Given the low star count, also review the last commit date and open issues to judge maintenance status. Run a quick spike on a branch against a non-production environment to confirm compatibility.
- Where should the protection middleware go in the Laravel middleware stack?
- Place it early in the web middleware group, after session start and before authentication or authorization middleware. That ordering ensures the password form renders correctly and the session flag is available. If you attach it only to a route group, audit coverage with route:list. Keep the placement documented so future middleware changes do not bypass the gate.
- Can I use it for a staging site while allowing health checks and webhooks through?
- Yes, but you must explicitly allowlist routes that external systems call, such as health checks, webhooks, and asset routes. Apply the middleware to a route group or the web stack and exclude those endpoints deliberately. Verify the allowlist with a route:list audit before rolling out. Remember that enabling the gate without an allowlist can lock out monitoring and integrations.
- Does it work for API-only, stateless, or token-authenticated SPA applications?
- It is a poor fit for API-only or stateless services because it relies on a shared session store and a password form. Token-authenticated SPAs and multi-tenant apps needing per-tenant gates are also outside its design. For Inertia or Livewire apps, verify the password form renders outside your normal layout and that XHR requests receive a redirect rather than a JSON 401.
- How is the password stored and can I rotate it without redeploying?
- The password is configured through Laravel-native configuration, typically fed by an environment variable or secret manager. Whether the package compares against a hash and whether rotation requires a redeploy are key questions to verify in the source. Treat it as a shared credential and plan a rotation runbook. Do not commit the password to a .env file in the repository.
- Does laravel-site-protection throttle brute-force attempts or log access?
- The overview does not describe built-in rate limiting or access logging, so treat those as open questions. For production use, add throttling to the password form and log successful and failed attempts. The package is not an audit system and should not be relied on for compliance access trails. Confirm behavior in the source before assuming protection.
- Will a CDN or response cache break the password gate?
- Yes, if caching is not configured correctly. A CDN or response cache could serve gated content or cache the password page for other visitors. Configure your edge cache to bypass or vary on the session cookie. Test this explicitly in staging before enabling the gate in production.
- What happens if the session backend is unavailable?
- The package depends on the session store, so failure behavior depends on your session driver and configuration. You need to determine whether it fails open, allowing access, or fails closed, blocking everyone. Test session failover across multiple instances and confirm the result matches your risk tolerance. Cookie sessions break under multi-instance deployments without sticky sessions, so prefer Redis or database sessions.
Weaver
How can I help you explore Laravel packages today?