- How do I install and set up lab404/laravel-impersonate in a Laravel app?
- Install it with Composer using composer require lab404/laravel-impersonate; the service provider is auto-discovered. From there you wire a gate or middleware, add a controller action that starts and stops impersonation, and add a button in your UI. The package does not ship routes or an admin screen, so those are your build items. Expect one to three engineer-days for the happy path in an existing Laravel app.
- Does laravel-impersonate work with multiple auth guards like web, admin, and api?
- Yes. Multi-guard support landed in 1.4.0 and was hardened in 1.7.2 for getImpersonator() and multi-guard exit, which matters if your product has separate web, admin, or api guards. Keep in mind impersonation state is session-based, so a stateless token-only api guard is not a fit. Verify each guard's session configuration independently.
- Can I impersonate users with UUIDs or non-integer primary keys?
- Yes. The package relies on Authenticatable@getAuthIdentifier() rather than a hardcoded integer id, so UUID keys, string keys, and custom models work as long as the model implements Laravel's Authenticatable contract. Any auth model without that contract is out of scope.
- Can I use laravel-impersonate with Sanctum or a stateless token API?
- No, not for token-only flows. Impersonation swaps the authenticated user on the existing session rather than minting tokens, so it is purpose-built for Laravel's native session guard. If your API is stateless, you need a different approach, such as short-lived scoped tokens issued by your own service.
- How do I restrict who is allowed to impersonate which users?
- The package ships helpers (is_impersonating, can_impersonate, can_be_impersonated), Blade directives, and optional middleware, but no policy or gate out of the box. You define who may impersonate whom in a gate or request-time policy, and enforce non-impersonable segments such as admins, billing roles, MFA-enrolled accounts, or regulated users there. In a multi-tenant app the tenant-scoping check is also yours to write, because the package will not enforce it for you.
- Does laravel-impersonate keep an audit log of impersonation?
- No. The package emits events when impersonation starts and stops but does not persist an audit record, so you subscribe to those events and write to your own log or SIEM. This matters for attribution: actions taken while impersonating are recorded as the user's actions in application logs and business data unless your audit trail stamps the impersonator's identity onto every write.
- Is there an automatic timeout or expiry for an impersonation session?
- No built-in TTL or auto-expiry is evidenced in the release history. The pitch material mentions configurable session timeouts via middleware, but the release notes do not confirm a shipped expiry mechanism, so verify it in a spike before relying on it. If it is absent, implement revocation yourself through session expiry, an explicit exit action, or logout of the impersonator.
- Which Laravel versions does laravel-impersonate support, including Laravel 13?
- Version bumps track Laravel releases rather than introducing features, and framework-compatibility releases have historically landed same-day-ish, which suggests fast turnaround. Laravel 13 (released 2026-03-17) support should be verified against the GA framework target you plan to run, since a fast release implies limited soak time. Check the Composer constraints and release notes before upgrading.
- What are the main security risks of shipping impersonation in production?
- Privilege escalation is the core risk: impersonation is effectively a session-hijack primitive, so a misconfigured gate turns a support convenience into an account-takeover path. Treat the gate as security-critical code with review and tests, and require strong authentication from the impersonator at the moment of impersonation. Also plan for attribution and GDPR concerns, plus session driver behavior across multiple nodes if you run Redis or database sessions behind a load balancer.
- How do I test impersonation, and is this package safe to depend on long-term?
- Test the gate and middleware like any other authorization code: assert that permitted actors can start and stop impersonation, that blocked users cannot, and that your audit listener fires. The package is small and stable but maintained by a handful of external contributors, so the bus factor is thin. Zero dependents means low ecosystem validation of edge cases, but also no transitive blast radius. Pin your version and review framework-compat releases before upgrading.