Laravel Impersonatable Guard Laravel Package

Product Decisions This Supports

• Support & customer-success tooling: enables "view as customer" / "log in as user" flows so support agents can reproduce bugs and see exactly what the customer sees, without asking for credentials or screen shares. This is a recurring roadmap ask in almost any B2B SaaS with a support function.
• Build vs. buy for impersonation: the alternative is a bespoke guard + session-swap implementation, which is deceptively fiddly (session regeneration, "return to admin" state, middleware exclusion, nested impersonation). A small package that swaps the auth guard is a defensible buy — but it is only the authentication primitive, not the full feature.
• Scope boundary for the feature: this package resolves "who is authenticated as whom." It does not give you the authorization policy (who may impersonate), the audit trail (who impersonated whom, when), the UI, or the safeguards against impersonating other admins. Treat those as first-party product work regardless of adoption — they are the parts audit/compliance will actually ask about.
• Platform upgrade planning: v3.0.0 is a major version bump whose headline is Laravel 13 support. That makes it a dependency in your framework-upgrade critical path: it either gates or unblocks the Laravel 12→13 migration. Sequence it into the upgrade epic rather than treating it as an independent ticket.
• Risk/roadmap signal: the release is overwhelmingly Dependabot dependency bumps with a single maintainer-authored compatibility commit. That is normal maintenance hygiene, not evidence of active feature investment. Do not plan roadmap bets on this package gaining capabilities (nested impersonation, audit hooks, UI) — assume you own anything beyond guard-swapping.

Read on this release specifically: v3.0.0 contains no new product capability. Its value is entirely "still maintained, still compatible." A major version number with a compatibility-only changelog usually means dropped support for older Laravel/PHP versions and possibly config or namespace changes — verify the actual constraint diff and upgrade guide before committing engineering time, because the release notes as written do not disclose breaking changes.

When to Consider This Package

Consider it when:

• You need guard-level impersonation and are on (or moving to) Laravel 13 — this release is the compatibility gate.
• Your team would otherwise hand-roll session/guard swapping, and you accept owning the surrounding authorization, audit logging, and UI yourselves.
• Your threat model tolerates a small, single-maintainer dependency in the authentication path — or you are prepared to vendor/fork it if it goes quiet.

Look elsewhere or build in-house when:

• You need auditability out of the box. Impersonation is a privileged-access feature; SOC 2 / ISO 27001 reviewers will want immutable records of who impersonated whom and when. If the package doesn't emit events you can hook, you're adding that anyway — weigh whether a fork is cheaper than a small first-party guard.
• Your security posture prohibits small third-party packages in the auth layer. This sits directly on the authentication boundary; supply-chain review cost may exceed implementation cost.
• You need rich behavior — impersonating without logging out the admin, multi-level impersonation, per-tenant restrictions, or a bundled admin UI. Scope these as product work, not package features.
• You are staying on an older Laravel major. A major bump may have dropped your version; confirm before assuming v3.0.0 is a drop-in.
• Your impersonation need is narrow and one-off (e.g., internal QA only, behind a feature flag, never exposed to customers) — the dependency overhead likely isn't repaid.

How to Pitch It (Stakeholders)

For executives (one line): A small, focused library that lets authorized staff sign in as a customer to resolve support issues faster — v3.0.0 keeps it current with our Laravel 13 upgrade; the business value is reduced support handle time, and the cost is that we still own the permissions and audit logging around it.

For engineering leadership:

• This package solves exactly one problem — swapping the auth guard for an impersonated user — and solves it competently. Everything a compliance reviewer will ask about (who is allowed to impersonate, the audit trail, the "return to admin" UX, admin-on-admin safeguards) is ours to build.
• v3.0.0 is a major version bump justified by Laravel 13 support, not by new features. Treat it as part of the framework-upgrade epic. Before merging, confirm what the major bump drops — the changelog is dominated by CI dependency bumps and does not enumerate breaking changes, so the composer constraint diff is the source of truth.
• Maintenance risk is real but bounded: single maintainer, low activity. Mitigations: pin the version, add it to the dependency-watch list, and keep the guard-swap thin enough that a fork or in-house replacement is a days-not-weeks effort.
• Recommended sequence: adopt v3.0.0 alongside the Laravel 13 upgrade → build authorization policy and audit events as first-party code → only then expose impersonation to support agents in production.

Ask: approve the upgrade as part of the Laravel 13 work, scoped explicitly as authentication primitive only, with audit logging and permission gating tracked as separate first-party deliverables. Do not let "we installed the impersonation package" be reported as "impersonation is done."