Weave Code
Filament Impersonate Laravel Package
xlite-dev/filament-impersonate
Filament plugin to switch between accounts without signing out. Supports linked accounts, impersonation with a switch-back banner, and environment-gated developer logins, plus an audit trail and a fluent per-panel API. Formerly xlite-dev/filament-impersonate.
Switch between accounts in Filament: impersonate users, linked sub-accounts with password-confirmed escalation, and one-click developer logins. The panel UI of packstub/account-switcher.
Frequently asked questions about Filament Impersonate
- How do I install the Filament account switcher plugin (xlite-dev/filament-impersonate)?
- The package was renamed: the composer package is now packstub/filament-account-switcher, so install it with composer require packstub/filament-account-switcher. Publish the config file and the migration, run php artisan migrate, then register AccountSwitcherPlugin on each Filament panel where you want the features. Finally, add the HasLinkedAccounts trait to your User model. The old xlite-dev/filament-impersonate name is frozen on Packagist and should not be used for new installs.
- Which Filament, Laravel and PHP versions does this plugin support?
- Version 4.x of the plugin supports Filament 4.x and 5.x, Laravel 12.x and 13.x, and PHP 8.2 or newer. If you are still on Filament 3 with Laravel 10 or 11, you would have to use the abandoned 3.x line under the old package name, which is not a good foundation for new work. Check the compatibility table in the README against your exact version matrix before committing.
- What is the difference between linked accounts and impersonation in this plugin?
- Linked accounts let two (or more) real accounts you control be tied together, so you can stay on a low-privilege account day to day and switch up to your admin account with a password prompt, then switch back down in one click. Impersonation is different: an admin acts as another user, using the ImpersonateAction on your user resource, a persistent banner with a Switch back button, and authorization hooks on the model. In short, linked accounts are you switching between your own identities, while impersonation is you acting as somebody else for support or debugging.
- Is it safe to use account switching and impersonation in production?
- The plugin is designed for production, but safety depends on your own authorization rules rather than on the package. It delegates decisions to canImpersonate() and canImpersonateBeImpersonated style model methods, with optional closure overrides such as canImpersonateUsing and canSwitchUsing, so your policies stay in your codebase where they can be security reviewed. The 4.0 rewrite also moved the leave route to a CSRF-protected POST inside the authenticated panel group. Start with only the feature you actually need enabled and add the others deliberately.
- What does the audit trail record and does it store personal data?
- Every switch is written to a single account_switches table and records who switched to whom, the reason, the panel, the IP address and the user agent, and it fires AccountSwitching and AccountSwitched events you can hook into. Because IP and user agent are stored by default, GDPR and retention obligations become yours, so plan an export and pruning strategy. Model the events if you need to forward entries to an external audit system.
- I upgraded from xlite-dev/filament-impersonate and get class not found errors — why?
- Version 4.0.0 was a hard rename: the vendor namespace changed and one Blade component was removed, so any application code referencing the old namespace will break. Follow the UPGRADE.md guide in the repository and update your imports, plugin registration and any published views. Also treat the rename as a signal that the old Packagist name no longer receives updates.
- How do I show one-click developer login buttons only in local or staging?
- Developer logins are one of the three per-panel feature toggles, enabled through the fluent plugin API, and the buttons are only rendered inside the environments you explicitly allow. Enable developerLogins() on local and staging panels only and never on a production panel. Because it is configured per panel, you can keep a dedicated local panel rather than conditionals scattered through service providers.
- Does the plugin work on tenant-aware Filament panels?
- Yes, but version 4.0.4 is a hard floor: earlier 4.0.x releases threw a Missing required parameter [tenant] exception on tenant-aware panels. Pin to 4.0.4 or above rather than 4.0.0, and test switching, the banner and the switch-back route against your tenant routing in a staging environment. If your panels are single-tenant, this does not affect you but pinning is still wise.
- Can I use this alongside lab404/laravel-impersonate, or for stateless API auth?
- Version 4.0.0 removed the lab404/laravel-impersonate dependency, and running both impersonation mechanisms side by side is not recommended because they share session keys and become hard to debug. The design is session-based, so it does not apply to stateless or API-token contexts. If you only need impersonation and already use lab404, keep one mechanism rather than two.
- Is this package actively maintained, and what are the risks of adopting it?
- It is a single-maintainer, single-vendor package with a small install base, so the main risk is project continuity rather than code quality. Mitigations are straightforward: pin a specific version above 4.0.4, diff the dist archive and verify release metadata before upgrading, and read the changelog for the early 4.0.x churn. Plan an exit route, since the HasLinkedAccounts trait sits on your User model and extraction is work you would own.
Weaver
How can I help you explore Laravel packages today?