- How do I install packstub/filament-account-switcher in my Laravel app?
- Install it with Composer using composer require packstub/filament-account-switcher, then publish the package config and migrations with the vendor:publish command. Register the plugin on your Filament panel provider, the same way you register other Filament v5 plugins. Finally, define who may switch to whom, since the package does not decide your impersonation policy for you. Your app must already run Laravel with Filament v5 and Livewire.
- Does this package support Filament v4 or only Filament v5?
- packstub/filament-account-switcher is built as a Filament v5 panel plugin and tracks v5 only, so it is not a drop-in for Filament v4 panels. It also requires Laravel and Livewire alongside Filament. Before committing, check the package composer.json PHP and filament/filament constraints against your pinned versions, because Filament majors move quickly. If your admin surface is not Filament v5, this package is not the right fit.
- How do I control which users can impersonate which accounts?
- Authorization is the real integration work here: impersonation is a privilege-escalation primitive, so you must own the allow-list of which roles may impersonate and which accounts are targetable. The plugin gives you the switching UI, but it does not ship an opinionated organisation-wide policy for you. Check exactly what hook it exposes, whether that is a Gate, a policy, or a config closure, and confirm you can express rules like role X may impersonate role Y but never role Z without patching. Verify your user model's guard matches the panel's auth guard before enabling impersonation.
- Does the plugin write an audit record when someone impersonates another user?
- Audit behaviour is not clearly documented, so treat it as something you must verify in the source before shipping. For production use you want an explicit event for every impersonation start and stop, tied to the original actor, the target account, and the timestamp. If the package does not emit that, log around it in your own middleware or listener and route it into your existing audit pipeline. Do not rely on the session alone as the record of who acted as whom.
- What are developer logins and can I disable them in production?
- Developer logins are one-click sign-ins intended as a local and staging convenience, and they are one of the two highest-severity features the plugin ships alongside impersonation. Confirm whether they are hard-disabled outside local and staging or merely gated by config, and check what the default is. If the default is permissive, add an explicit production guard in your panel provider or environment config before deploying. Treat any environment where they are enabled as an account-takeover surface.
- How do linked sub-accounts with password-confirmed escalation work?
- The plugin supports linked sub-accounts where escalating into a parent or child account requires password confirmation, which is a meaningful control worth adopting rather than bypassing. It assumes your user model actually represents a parent and child account relationship, either through a self-referential parent_id, a pivot table, or a contract you implement. If your schema has no such relationship, the linked-accounts feature is either unused or requires a schema decision first. Read the package contract before designing migrations around it.
- Does it work with multi-tenant Filament panels?
- Version 4.0.4 fixed a Missing required parameter tenant error when building the linked-accounts URL on tenantless pages, so tenant support exists but tenant route generation has been a live regression area. Test custom panel paths, additional tenant-scoped pages, and clustered panels against your own tenancy setup. If you run a single-tenant panel, this is mostly irrelevant to you. If you run tenants, plan explicit QA around the switcher links on pages without a tenant context.
- What happens to the original session when impersonation ends?
- Session semantics are not spelled out in the overview, so verify them yourself: does the original session persist so the admin can return cleanly, and what happens if the session expires mid-impersonation? Also check how the package interacts with two-factor authentication, password confirmation middleware, and remember-me cookies. A clean return path matters as much as the switch itself, because a stranded impersonated session is an operational and security problem. Test these flows on a staging panel before enabling the feature for real administrators.
- Is packstub/filament-account-switcher production-ready?
- It is a single-maintainer project with roughly 45 stars and no dependents, so you would be an early adopter absorbing discovery cost. The maturity signals are positive but narrow: an export-ignore dist archive, CI replicating Filament package-health checks, SHA-pinned actions, Dependabot with cooldowns, a security policy, and weekly score gating. The release metadata also looks anomalous for its history, so verify the tag resolves and pin to a commit SHA rather than trusting the feed. That raises confidence in maintainer quality but does not replace your own threat model.
- Can I use it outside a Filament panel, such as in an API or CLI?
- No. The package renders into Filament's user menu and switcher menu through a panel plugin, and it has no headless API or framework-agnostic layer. Any non-Filament admin surface, CLI tool, or API-driven support tooling would require separate implementation work. It is also not a general multi-account library for public-facing apps, only an admin panel switcher. If you need programmatic impersonation, build that path yourself and reuse the plugin only where Filament renders the UI.