Auto Login Laravel Package

Getting Started

The first thing to internalize is the framing: jmikola/auto-login is a Symfony Security component bundle, not a Laravel package. There is no service provider, no facade, no config file at config/auto-login.php. If you are a Laravel developer, you will not composer require jmikola/auto-login into a Laravel app and be productive — you will either be working in a Symfony application (or a hybrid/legacy codebase that ships one), or you are reading it as a reference implementation for one-time-token login. Plan accordingly.

Minimal steps in a Symfony context:

1. composer require jmikola/auto-login — pin the version against your Symfony major. The current tag is 2.0.3, a patch that (per its release notes, PR #25) splits the Security component dependencies to fix Symfony 5.0 compatibility. That is the entire scope of the release: it makes dependency resolution clean on Symfony 5.0, and it tells you the package's supported target is the Symfony 4.4/5.x line. It does not address Symfony 6's security refactor or the security.authenticator era, so expect it to work cleanly on 4.4/5.x and expect to fight it on 6.x. Run composer why-not before assuming compatibility.
2. Register the bundle (Symfony ≤5: in config/bundles.php). Look for a Security directory containing the listener and token provider — that is the actual implementation, not the README.
3. Configure a firewall entry that names the listener and a query-parameter token name (e.g. ?_token=… or ?t=…). The firewall is the integration point; nothing auto-registers itself.
4. Ensure your UserProvider can resolve the user referenced in the token (this is where 90% of first-run failures come from — the token validates but there is no loadUserByUsername match).

Where to look first: the README for the firewall configuration shape, then the listener and the token provider classes. The README is thin; the listener is where the actual contract lives. Treat the firewall snippet as the API.

First use case: a "magic link" — an emailed URL that logs a user in without a password. Generate a token bound to the user, embed it in a URL, and when the user clicks it, the listener authenticates them for that request and (ideally) marks the token consumed.

Implementation Patterns

Magic-link / passwordless flow. This is the package's reason for existing. Store a token with the user id, an expiry, and a "consumed at" column; generate it on request; email a URL containing the token; the firewall listener authenticates the matching user; a post-authentication step flags the token consumed. The security of the whole flow lives in your token lifecycle, not in the bundle.

Email verification and invitations. Same primitive, different framing. An invitation token that logs the recipient in is a nice UX but means the invitation email is the credential — treat it accordingly (short expiry, single use, no logging of the raw token).

Admin impersonation. A staff member generates a short-lived token targeting another user. This is where the single-token design is convenient and exactly where you must add an audit trail, an expiry measured in minutes, and a hard "impersonation sessions cannot change passwords / grant roles / delete account" rule.

Integration shape that actually works. Keep the token storage and issuance in your own domain code (a LoginToken entity or service), and let the bundle handle only the authentication check. Do not try to push generation logic into the bundle; it doesn't want it. Your issuance step is: create record → return URL → caller emails it.

For Laravel developers specifically: the equivalent day-to-day pattern is URL::temporarySignedRoute() + a route that calls Auth::loginUsingId($user->id). If you find yourself wanting this bundle's behavior in Laravel, you almost certainly want signed URLs or a magic-link package, not this bundle. Reserve jmikola/auto-login for Symfony applications where you are the maintainer, and treat reading it as "how does the token-auth listener wire into a security firewall" — that is transferable knowledge.

Testing pattern. Test the token lifecycle independently of the firewall (issuance, expiry, consumption, invalid signature). For the firewall itself, one functional test that hits the route with a valid token and one with a tampered token is enough; the bundle is old and stable, your token logic is what changes.

Gotchas and Tips

It is not a Laravel package and does not pretend to be. No config/, no Artisan command, no facade. If your task is "add magic links to Laravel," close the tab and use url()->temporarySignedRoute(). If your task is "understand or maintain this in Symfony," go ahead.

Version drift is still the biggest practical risk — but 2.0.3 is a real signal. The package has now shipped a targeted compatibility patch, which tells you (a) someone is still applying fixes, and (b) the fixes are narrow: splitting Security component constraints so composer resolves on Symfony 5.0. Nothing in 2.0.3 changes runtime behavior, the listener contract, or the firewall configuration shape, so an existing install can upgrade as a low-risk patch. What it does not do is bring you Symfony 6 support, modern authenticator migration, or broad test coverage. Pin it, read the listener before you trust it, and budget for a fork (or a rewrite as a native AuthenticatorInterface guard) if you are on Symfony 6+. If you were previously blocked from installing on a Symfony 5.0 app, 2.0.3 is worth retrying first — that is precisely its use case.

Firewall ordering. Symfony evaluates firewalls in declaration order. A security: false or a broader firewall earlier in the list will shadow your auto-login firewall and the token will silently do nothing. Debugging hint: dump security.firewalls and confirm the request matches the intended one; a 200 with an anonymous user is the classic symptom.

The user provider is the real dependency. The token identifies a user, but your UserProvider resolves it. If the identifier in the token does not match what your provider expects (username vs. id vs. email), authentication fails with no obvious error. Assert the exact identifier contract in a unit test.

Single-use is on you. The bundle authenticates a token; it does not (in a way you should rely on) guarantee the token cannot be replayed. Add a used_at/invalidated_at column and check it in the listener path or a kernel event. This is the single most common security defect in magic-link implementations — a leaked email URL is a permanent login until you make consumption atomic. Use a DB-level conditional update (UPDATE … WHERE used_at IS NULL) rather than a read-then-write, to avoid races.

Expiry is on you, too. Prefer short-lived tokens (minutes, not days) and store the expiry with the token, not in a signed URL alone. Clock skew across servers will bite you; compare against the DB clock or a single trusted source.

Never log or serialize tokens. They are credentials. Keep them out of exception messages, analytics, and referrer-leaking query strings where possible (the bundle's query-parameter design makes referrer leakage a real concern — set a Referrer-Policy header and consider redirect-on-consume).

Extension points worth knowing. The custom UserProvider and a custom token provider are where you should adapt the package to your app; do not subclass the listener. If you need post-authentication hooks (mark consumed, audit, redirect), use a kernel event listener on the authenticated event rather than editing vendor code.

Debugging checklist when "nothing happens": (1) firewall match order, (2) token parameter name in the query string vs. configured name, (3) user provider identifier mismatch, (4) token already consumed/expired, (5) Symfony security logging at debug for that channel. Most "it doesn't work" reports collapse to (1) or (2).

Bottom line for a Laravel developer's day-to-day: this is not a tool you reach for. It is a compact, readable example of token-based authentication against a security firewall — useful as a pattern reference, useful if you inherit a Symfony app that depends on it, and a liability if you adopt it into a greenfield project without auditing it for your Symfony version. Release 2.0.3 is a good-news patch only in the narrow sense that it unblocks Symfony 5.0 installs; it does not change the strategic picture.