Laravel Anypass Laravel Package

Getting Started

Install it as a dev-only dependency so it never reaches production:

composer require --dev imanghafoori/laravel-anypass

Laravel 5.5+ auto-discovers the service provider. If you're on an older skeleton (or have discovery disabled), register Imanghafoori\AnyPass\AnyPassServiceProvider in config/app.php. Publish the config if you need to change the default password or toggle:

php artisan vendor:publish --provider="Imanghafoori\AnyPass\AnyPassServiceProvider"

Then open config/anypass.php and set the value from your .env:

# .env (local only — never commit a real value)
ANY_PASS=dev-only-secret
APP_ENV=local

Where to look first: config/anypass.php (the actual switch and password), then vendor/imanghafoori/laravel-anypass/src/ to see which auth hook it uses in your installed version — the package works by short-circuiting credential validation for the Eloquent user provider, so the exact integration point matters if your app has custom guards.

First use case: log in as a seeded admin (or any user from an imported production dump) whose password you don't know. Go to your normal login page, enter that user's email and ANY_PASS as the password. No code changes, no database update, no password reset email.

Implementation Patterns

Standard Auth::attempt() login. This is the happy path. If your controller calls Auth::attempt($credentials) and the user provider is Eloquent, AnyPass intercepts the password check and lets the attempt succeed. Leave your login controller alone.

Fortify / Breeze / Jetstream. These ultimately call Auth::attempt() under the hood, so the standard session login flow usually works unchanged. The catch is anything layered on top — two-factor challenges, password confirmation middleware, or custom Hash::check calls in your own code — which AnyPass does not bypass.

Custom login controllers. If you hand-roll authentication with Hash::check($request->password, $user->password) instead of Auth::attempt(), the package never sees the request. Either switch to the guard's attempt() or add a local-only branch:

if (app()->isLocal() && $request->password === config('anypass.pass')) {
    Auth::login($user);
}

API / token auth (Sanctum, Passport). Token issuance doesn't go through the session guard's password validation, so AnyPass won't help there. For API work, use Auth::loginUsingId() in tinker or generate a token directly:

php artisan tinker
>>> Auth::loginUsingId(1);
>>> $user->createToken('local')->plainTextToken;

Browser QA and demos. This is the package's strongest use case: manually clicking through the app as different roles (admin, customer, suspended user) without maintaining a password spreadsheet. Pair it with seeders that create one user per role, and switch identities by re-submitting the login form with a different email.

Team onboarding. Put ANY_PASS= (empty) in .env.example, document the value in your team password manager, and let each developer set their own locally. New hires can log in as any seeded persona on day one.

Testing. Don't use AnyPass in automated tests — $this->actingAs($user) is faster, explicit, and doesn't depend on config. Reserve AnyPass for manual browser sessions and Dusk-style smoke runs where you want to exercise the real login form.

Gotchas and Tips

Production safety is on you. The package is a dev convenience, not a security boundary. Three layers of defense: install with --dev, run composer install --no-dev in production, and add an assertion in a service provider that throws if app()->isProduction() and the package is enabled. A leaked ANY_PASS on a public host is a full account takeover for every user.

Config caching bites. php artisan config:cache bakes anypass.pass into the cached config. If you change .env and logins still fail, run php artisan config:clear (and config:cache again if that's your deploy step).

Password confirmation still asks for the real password. Middleware like password.confirm and sensitive-action re-auth don't use the login attempt path. You'll be prompted for the actual password even after logging in with AnyPass. Disable those routes locally or keep a known password on your seeded admin.

2FA and rate limiting. Fortify's two-factor challenge still fires after a successful password check, so you'll need to disable 2FA on the test account or have recovery codes handy. Conversely, repeated failed attempts can trip the login throttle and lock you out for a minute — clear the cache or wait.

Custom user providers may not be covered. LDAP, multi-tenant, or fully custom providers that don't extend Laravel's Eloquent provider won't inherit the override. Check which provider your config/auth.php guard uses; if it's custom, you'll need to replicate the bypass in that provider.

Silent failures are usually config. If the login just redirects back with "These credentials do not match," verify in order: APP_ENV, the exact env key name the config reads, whether config is cached, and whether the guard in use is the one the package hooked.

Project maturity. At ~216 stars and zero dependents, this is a small, single-maintainer utility. Pin the version in composer.json, keep the integration surface to zero lines of app code (so removal is just composer remove), and don't build team workflows that assume it will be maintained forever. Auth::loginUsingId() in tinker and Laravel's impersonation packages cover most of the same ground if you ever need to drop it.

Removal is clean. Because it's a dev dependency that hooks the provider rather than modifying your models or controllers, composer remove --dev imanghafoori/laravel-anypass plus deleting config/anypass.php fully uninstalls it.