Statamic Impersonator Laravel Package

Product Decisions This Supports

• Build vs. buy for "log in as customer": this package is the buy option for impersonation in Laravel apps. It removes a recurring backlog item (admin session swapping, guard handling, redirect-back logic, authorization gates) that otherwise gets rebuilt poorly by each team.
• Support & CX roadmap: underpins "view as user" for support tiers — resolving access/permission tickets by seeing the exact UI and entitlements the customer sees, instead of screen-shares and guesswork. Directly supports deflection-rate and time-to-resolution goals.
• QA and reproduction workflows: engineers and QA can reproduce tenant-, role-, or plan-specific bugs without harvesting credentials or seeding accounts, shortening the repro loop in the defect lifecycle.
• Audit and compliance posture: v2.6.0 fixes the impersonated user's last_login_at being overwritten during an impersonation session. Product impact: activation/DAU/"last seen" metrics are no longer polluted by support activity, and user-facing security notices ("new sign-in from…") stay truthful. This is a data-integrity fix that de-risks an audit finding — worth flagging if login timestamps feed analytics, churn scoring, or account-takeover alerts.
• Roadmap signal, not a feature: a one-line patch release signals a maintained-but-stable dependency. Budget for version pinning and periodic review, not for active co-development.

When to Consider This Package

Adopt when:

• The product is Laravel/PHP and already has an internal admin, support, or success console that could host a "log in as this user" action.
• You need policy-driven authorization (who may impersonate whom), multi-guard/session handling, and a clean return to the admin's own session — the parts teams most often get wrong.
• You want a defensible audit trail: impersonation is explicit, reversible, and does not silently mutate the target account's login history (the v2.6.0 behavior).
• The team is small and prefers a focused, MIT-licensed dependency over an in-house subsystem.

Look elsewhere when:

• You need session replay, console/network capture, or a full customer-support suite (FullStory, Sentry, Intercom-style tooling) — this is an authentication mechanism, not an observability product.
• Compliance requires privileged access brokered through a vaulted/SSO-gated path with approval workflows and per-action recording; impersonation must then be wrapped in your own access-review process, and this package alone will not satisfy the control.
• The real need is field-level data masking or "view as role" previews that never touch the user's actual session. Prefer a scoped preview mode; impersonation carries real write access and its own blast radius.
• You are not on Laravel, or you are on an unsupported Laravel/PHP combination — verify compatibility before committing the roadmap item.

How to Pitch It (Stakeholders)

For executives: a small, mature open-source Laravel package that lets authorized staff securely sign in as a customer to resolve issues. It is the cheapest credible path to faster support resolution and fewer "I can't reproduce it" escalations, with no licensing cost and negligible infrastructure impact. The latest patch closes a data-integrity gap so support activity no longer distorts customer login history and related metrics — a small but meaningful win for audit and analytics trustworthiness.

For engineering: install-and-configure, guard-aware, policy-gated, and already handles the hard edges (session handoff, return-to-admin, redirect targets). v2.6.0 is a targeted bugfix — impersonation sessions no longer update the impersonated user's last-login timestamp — so treat it as a low-risk patch upgrade; no API changes, no migration work. Pin the version, add a test asserting last_login_at is untouched during impersonation, and gate the feature behind an explicit permission plus audit logging on entry and exit.

Recommendation: adopt for the internal support console; upgrade to v2.6.0 on the next maintenance window; revisit only if compliance requires vaulted privileged-access workflows.