- Can I use jmikola/auto-login in a Laravel application?
- Not directly. The package plugs into Symfony's Security component by registering a request listener/authenticator on a firewall and issuing a token against Symfony user providers and token storage. Laravel's authentication stack (Illuminate\Auth\AuthManager, session and guard drivers, Sanctum, Fortify) never consumes symfony/security-http or symfony/security-core, so the package has no anchor point in a Laravel app. Making it work would require either running Symfony Security alongside Laravel's auth or porting the token logic into a custom Laravel guard.
- How do I install jmikola/auto-login?
- It is a Symfony bundle, so installation is composer require jmikola/auto-login followed by enabling the bundle in a Symfony kernel and wiring the auto-login listener into a firewall in security.yaml. There is no Laravel service provider, facade, config publish, or middleware registration path for it. If you run composer require inside a Laravel project, expect dependency resolution to fail or to pin Symfony components in ways that block future framework upgrades; confirm with composer why-not jmikola/auto-login before attempting a spike.
- Does jmikola/auto-login support Laravel 10 or Laravel 11?
- No. The package targets Symfony's security layer, and its last release was 2021-06-29, which predates current Laravel and Symfony 6.x/7.x constraints. Laravel 10 and 11 ship with newer Symfony components (http-foundation, console, routing), so the package's Composer constraints will likely conflict. Run composer why-not jmikola/auto-login to see the exact blocker; either a hard failure or a successful install that pins components is a poor trade.
- Is jmikola/auto-login compatible with Laravel Sanctum or Fortify?
- No. Sanctum and Fortify are built on Laravel guards, the AuthManager, and session or token drivers, while this package authenticates through Symfony's firewall and token storage. They solve overlapping problems but share no integration surface, so you cannot hand a Symfony security token to Sanctum or Fortify. For Laravel passwordless or one-click flows, use signed URLs plus Auth::login and session regeneration, or Fortify's built-in features.
- Is jmikola/auto-login safe for production authentication?
- Treat it as high risk. It is login-path code, which is security-critical: token entropy, hashing at rest, single-use enforcement, TTL, constant-time comparison, uniform error responses to prevent user enumeration, rate limiting, session regeneration, and invalidation on password change all matter, and the project shows no evidence of recent security review. With one maintainer and zero dependents, no downstream users are exercising the code in production. Most organizations should not accept unmaintained auth code without a fork and an explicit owner.
- How does jmikola/auto-login trigger automatic authentication?
- It uses a pluggable, request/listener-based trigger that intercepts an incoming request matching its configuration and signs in the configured user without posted credentials. Configuration controls when auto-login fires and which user is authenticated, and the resulting token is stored through Symfony's token storage so the session behaves like a normal firewall login. This design is tied to Symfony's request/security event pipeline, not Laravel middleware or guards.
- What are the Laravel alternatives to jmikola/auto-login for one-click or magic-link login?
- Use Laravel-native primitives: URL::temporarySignedRoute for tamper-evident links, a hashed token column with expires_at and consumed_at, a controller that calls Auth::login followed by session()->regenerate(), RateLimiter for throttling, and notifications for delivery. For staging or internal-only login links, spatie/laravel-login-link is a far better fit than this package. For a broader auth surface, evaluate Laravel Fortify.
- Can I use jmikola/auto-login for functional testing instead of actingAs()?
- No, and you should not try. The package is useful in Symfony functional tests, but Laravel's test suite has $this->actingAs($user) and Auth::login(), which authenticate a user for the request without touching URL tokens or firewalls. Using a real auto-login token in tests adds session and listener complexity with no benefit. Keep test authentication in Laravel's built-in helpers.
- Is jmikola/auto-login still maintained?
- The last release was 2021-06-29, with a single maintainer, roughly 99 stars, and zero dependents. There is no evidence of recent security review, and no downstream users exercising the code in production. Before depending on it, confirm whether a maintained fork or vendor is willing to own patches, and write down who is accountable for security fixes.
- What would it take to port jmikola/auto-login's token login to Laravel?
- It is a small build, not a migration. Isolate token minting and validation into a service class, bind it to a custom guard or a dedicated login route rather than a firewall listener, reuse Laravel's signed URLs and hashing, and call session()->regenerate() after Auth::login. Add tests for replay, expiry, and user enumeration, and write a one-page threat model first. Timebox a one-to-two day spike on the Laravel-native prototype before considering the dependency.