Weave Code
Dev Login Laravel Package
ageekdev/dev-login
A Laravel package for quick developer login, letting you authenticate as any user during local development so you can test role-based flows without passwords. Useful for debugging and demos.
Developer Login For Laravel
Frequently asked questions about Dev Login
- What is ageekdev/dev-login used for in Laravel?
- ageekdev/dev-login is Laravel developer-experience tooling that lets an engineer authenticate as any existing or seeded user during local development, so role-based flows, permissions, and multi-user screens can be tested without passwords. It is intended for local and testing environments only. It is not application architecture or a product capability, so treat it as a require-dev dependency rather than a platform dependency.
- How do I install ageekdev/dev-login in a Laravel app?
- Install it as a dev-only dependency with composer require --dev ageekdev/dev-login, then publish any config the service provider exposes. Set the package's environment or enable flag to a disabled-by-default posture and register it only when the app environment is local or testing. Verify the package's guard and user provider assumptions against your app before using it, and confirm no schema migrations are introduced.
- Is ageekdev/dev-login safe to use in production?
- No. Any mechanism that logs in as any user is an authentication bypass if it is reachable outside local, and this package's evaluation flags single-flag gating as a common failure mode. Register it only in local/testing, keep it out of production code paths, and add a CI check that fails if its routes or provider are active with APP_ENV=production. Treat the 9-star, single-maintainer status as a reason for extra review, not as evidence of production hardening.
- Which Laravel and PHP versions does dev-login support?
- Supported Laravel and PHP ranges are declared in the package's composer.json, and the provided evaluation does not confirm a CI matrix or a detailed compatibility list. Check the constraint matrix and tags against your target app, especially if you run Laravel 10, 11, or 12 with a specific PHP version. Do not assume compatibility from the recent release date alone.
- Does dev-login bypass two-factor authentication and password checks?
- The evaluation context does not document behavior around two-factor authentication, password expiry, account-status checks, tenant scoping, or multi-guard setups. Because the package short-circuits the normal authentication flow, you should assume it bypasses those checks until you verify otherwise. Test the exact flows you rely on, and document the result in your security note before adoption.
- How do I disable dev-login outside local and testing environments?
- Wrap registration in an environment check in AppServiceProvider, or use composer.json extra.laravel.dont-discover plus manual registration, so the provider is never registered outside local and testing. Publish the config with a disabled-by-default flag and avoid always-registered routes. Add a CI guard that fails the build if the package's routes or service provider are active when APP_ENV=production.
- Will dev-login conflict with Fortify, Jetstream, Breeze, or Sanctum?
- Possible route-name and middleware collisions with Fortify, Jetstream, Breeze, or Sanctum are a real risk, and the provided context does not confirm how the package namespaces its routes. Check route names, middleware groups, CSRF, rate limiting, and guard assumptions before installing. Test in a branch that mirrors your actual auth stack, including Sanctum and custom user providers.
- Does dev-login expose user lists or PII?
- The evaluation flags possible exposure of user lists and PII/enumeration as an unknown risk, and the context does not say whether the list is scoped or disabled by default. Review the package's routes and any Blade or UI surface before use, and keep it off shared or non-local environments. If a user list is rendered, scope it and treat it as sensitive developer data.
- How should I test dev-login in CI, including guard mismatches?
- Add a CI job that runs with APP_ENV=production and asserts that the package's routes are absent and its provider is not registered, proving the package is inert. Also cover local login behavior with feature tests and explicitly test guard mismatch cases such as web versus sanctum to see whether the package fails loudly or silently no-ops. Verify behavior with your actual session driver and any custom user provider.
- What are alternatives to ageekdev/dev-login and is it worth adopting?
- Cheaper alternatives include an in-house route or Artisan command guarded by APP_ENV that calls Auth::loginUsingId(), using tinker for one-off logins, or writing feature tests with actingAs() for repeatable role flows. Given the low opportunity score, low star count, single-maintainer bus factor, and trivial rollback, the sensible default is a short trial in one low-criticality repo or a roughly one-day in-house replacement. Adopt broadly only if the security review and pilot show clear value.
Weaver
How can I help you explore Laravel packages today?