Getting Started

Install with composer require esplora/auto-login, then publish any package config/routes if the README instructs it (php artisan vendor:publish --tag=auto-login-config or similar).
Look first at the README, config/auto-login.php if present, the package service provider, and any registered routes/middleware. These tell you the supported guard, user resolver, route prefix, and security model.
Treat 1.0.0 as the initial stable baseline. The release notes only link to the changelog, so pin to ^1.0 and review the changelog diff if you were previously on a pre-1.0 tag.
First use case: in a local or staging environment, generate a temporary login URL or enable auto-login for a known test user. Verify the flow end-to-end before wiring it into admin impersonation or magic-link workflows.

Implementation Patterns

Local development login switching: enable the package only in local/testing, restrict allowed users by ID/email, and keep the feature behind an environment flag. This is the lowest-risk day-to-day use.
Admin impersonation: from an admin action, generate a signed/temporary login URL for the target user, redirect to it, and record an audit entry. Provide a clear “return to admin” or “stop impersonation” path if the package supports it.
Magic-link style access: use the package’s URL/token helper to create expiring links, send them through notifications or mail, and validate expiry/single-use behavior before using them for non-admin flows.
Guard and model configuration: explicitly set the guard, provider, and user model when your app uses multiple guards. Do not assume the default web guard is correct.
Testing: use the package route/helper in feature tests to authenticate quickly, but also assert that the route is unavailable in production-like environments and that expired/invalid links fail.
Route and config changes: after changing package config or route registration, run php artisan config:clear and php artisan route:clear locally; in deployment, ensure your normal cache rebuild steps include the package config.

Never expose unrestricted auto-login in production. Require signed URLs, short expiry, authentication/authorization, rate limiting, or an IP allowlist depending on the use case.
Session behavior is not the same as normal login. Check whether the package regenerates the session, handles remember-me tokens, and interacts correctly with logout and password confirmation.
Token/URL leakage matters. Avoid logging full login URLs or tokens; they are credentials. Redact them in logs and exception trackers.
Expiry and single-use semantics need verification. Confirm TTL, replay behavior, and what happens after the user logs out.
Route/model assumptions can break. If your app uses custom guards, UUIDs, soft-deleted users, or non-standard user models, configure the resolver explicitly.
Caching can mask changes. Config cache and route cache are common reasons package settings “do not apply” after edits.
Debug with route:list and middleware order. If a login URL fails, inspect the registered route, middleware stack, signature validation, APP_URL, and trusted proxy configuration.
Prefer extension points over forking. Put app-specific redirect logic, user resolution, and audit behavior in your own service provider or action classes if the package exposes callbacks/events; otherwise keep a thin wrapper around the package API.