Laravel Impersonate Laravel Package

Product Decisions This Supports

• Build vs. buy for impersonation: "log in as another user" is a commodity capability with real security sensitivity. This package lets the team buy rather than build, reserving engineering time for the differentiation layer.
• Support & operations tooling roadmap: Unblocks or de-risks features in the admin/support console — CS agents reproducing customer issues, QA validating role-specific UI without seeded credentials, and demos that start from a real account.
• Dependency-footprint decisions: v5's zero-dependency frontend (no jQuery/Select2/Node build chain) removes a webpack/package.json surface from our supply chain, which is a security and maintenance argument as much as a performance one — worth flagging to anyone who owns dependency policy.
• Build-vs-buy cost baseline: scopeImpersonatable + trait defaults + Impersonate::loginAs($user) mean the "integrate" estimate drops to roughly: install, add a scope, wire an authorization gate, ship. That's the number to compare against an internal build.
• Platform-version sequencing: The PHP 8.2 / Laravel 12–13 floor makes this package a forcing function aligned to our framework upgrade calendar, not an independent decision. It should appear in the Laravel-upgrade epic, not as a standalone ticket.
• Compliance/audit is not bought here: The package authenticates the switch; it does not provide an audit trail, consent capture, or session-policy enforcement. That's a product requirement we own and must scope separately.

When to Consider This Package

Adopt when:

• We are on (or imminently moving to) PHP 8.2+ and Laravel 12/13. Below that, the package is simply unavailable.
• The need is in-app impersonation from an authenticated admin surface — support, QA, demos — and we want a small, self-contained solution rather than a sprawling auth framework.
• We want to avoid a Node/frontend build toolchain for a small UI widget.
• We can accept a third-party, single-maintainer package in the auth path, with our own authorization gate, audit logging, and session invalidation wrapped around it.
• We are currently on v4.x and exposed: the HIGH-severity information disclosure fix (unauthenticated user enumeration via /_impersonate/users and /_impersonate/login) is, on its own, sufficient reason to schedule the upgrade.

Look elsewhere when:

• We are pinned to Laravel 10/11 or PHP 8.1 for the foreseeable future — the version floor makes this a non-starter until the platform moves.
• We need built-in audit logging, consent flows, or SSO/SAML-aware impersonation — those must be built around this package regardless, which weakens the buy case.
• We require vendor SLAs, long-term support guarantees, or broad community adoption in the authentication path. A package whose major release is still shipping breaking config-key renames and dropping in-memory filtering (forcing a migration step) carries churn risk that should be priced in.
• We cannot absorb periodic major-version migrations (env var renames, config restructuring) alongside our own release train.
• We want an impersonation layer with more mature, higher-adoption alternatives already vetted by our security team.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated LaraPersonate, a Laravel package that lets trusted staff sign in as another user for support, QA, and demos. Version 5 is a genuine maturity jump — the frontend dependency tree is gone entirely (smaller attack surface, less to maintain), the codebase now passes strict static analysis with no suppressions, and a high-severity information-disclosure vulnerability was fixed: unauthenticated users could previously enumerate your customer list through the package's API endpoints. If we run it anywhere in production on v4, upgrading is a security action, not a nice-to-have. The trade-off is a hard requirement on PHP 8.2+ and Laravel 12/13, plus a short but mandatory migration (renamed config/env keys, adding a database scope to the user model). Recommendation: upgrade immediately if we are already on v4 and a supported Laravel version; otherwise fold adoption into the next Laravel upgrade rather than starting a separate workstream.

For engineering (the working summary): Cleaner, smaller, stricter. Dropped jQuery/Select2 and the Node build; vanilla JS/CSS only. scopeImpersonatable moves filtering to the database, which fixes pagination .total() accuracy and improves search performance, and it now supports both scopeMethod() and Laravel 11+ #[Scope] attributes. Trait defaults (getImpersonateDisplayText() → $this->name, getImpersonateSearchField() → ['name']) mean zero config for basic use, and Impersonate::loginAs($user) gives a fluent backend path. Breaking changes to plan for: PHP 8.2+/Laravel 12–13; in-memory filtering is gone, so a scopeImpersonatable on the User model is now required, not optional; impersonate.enabled → impersonate.interface.enabled; IMPERSONATE_ENABLED/_WIDTH/_DELAY → IMPERSONATE_UI_ENABLED/_UI_WIDTH/_UI_DEBOUNCE. Non-negotiables we own regardless of version: an authorization gate on both API endpoints, audit logging of every impersonation start/stop, and session invalidation on exit — the package handles the login switch, not the governance around it.