Filament Account Switcher Laravel Package

Technical Evaluation

Architecture fit. packstub/filament-account-switcher is a standard Laravel package shaped as a Filament v5 panel plugin: src/, publishable config/, database/ migrations, and resources/ views registered through a panel provider. It delivers three distinct capabilities behind one plugin registration — user impersonation, linked sub-accounts with password-confirmed escalation, and developer logins — rendered into the user menu and switcher menu. That is a clean fit if and only if our admin surface is Filament v5. It is not a framework-agnostic solution and has no headless API; any non-Filament admin, CLI, or API-driven support tooling would need separate work. v4.2.1 does not change this shape: it is a UI refinement to the developer-login menu plus a docs correction, with no new surface area and no architectural movement.

Integration feasibility. Low mechanical effort, moderate policy effort. The install path is composer require → publish config/migrations → register the plugin on the panel → define who may switch to whom. The real work is authorization design: impersonation is a privilege-escalation primitive, so we must own the allow-list (which roles can impersonate, which accounts are targetable), the session semantics (does the original session persist for return), and the audit record. The package's password-confirmed escalation for linked sub-accounts is a meaningful control we should adopt rather than bypass, but it implies our user model actually models a parent/child account relationship — if it does not, the linked-accounts feature is either unused or requires a schema decision. v4.2.1 confirms the developer-login list is driven by a configurable search resolver, which is the practical extension point for pointing the switcher at our user model — and, correspondingly, the place where we decide which users are even discoverable through that menu.

Technical risk.

• Adoption risk (high signal, low confidence). 45 stars, 0 dependents, single-maintainer project. There is no evidence of production use at scale, so we would be an early adopter absorbing discovery cost. The 4.2.1 release is weak but positive evidence of a maintained project rather than an abandoned one.
• Privilege surface. Impersonation and developer logins are the two highest-severity features an admin panel can ship. A defect here is a full account-takeover path, not a UI bug. The v4.2.1 search-resolver work sits directly on that surface: it determines what the developer-login menu will enumerate and return.
• Multi-tenancy was recently patched. 4.0.4 fixed Missing required parameter … [tenant] when building the linked-accounts URL on tenantless pages. The fix (omit the link when no tenant is present) is correct but indicates tenant route generation is a live regression area. Custom panel paths, additional tenant-scoped pages, or clustered panels are plausible repeat surfaces. Nothing in 4.2.1 touches routing, so this risk is unchanged and still untested by upstream.
• Version drift against our review set. Our last reviewed point was 4.0.4; the current tag is 4.2.1. The 4.1.x and 4.2.0 notes were not supplied with this release, so the aggregate change since our review is larger than the 4.2.1 diff implies. Pull the full changelog and UPGRADE.md before pinning rather than treating this note as the delta.
• Release metadata anomaly. The stated last release (2026-10-15) is inconsistent with a v4.0.4 changelog for a package with this history; verify the tag actually resolves and pin to a commit SHA rather than trusting the feed. This remains unresolved and now applies to a higher version number.
• Maturity signals are positive but narrow. The 4.0.4 changes show disciplined engineering hygiene — lean export-ignore dist archive, CI that replicates the filamentphp.com package-health checks, SHA-pinned actions, Dependabot with cooldowns, a security policy, weekly score gating. v4.2.1 adds two small but real signals: continued delivery of polish work on the developer-login surface, and a portability fix in the docs (replacing PostgreSQL-only ilike with whereLike(..., caseSensitive: false)), which suggests the maintainer is widening driver support beyond Postgres rather than assuming their own setup. That raises confidence in maintainer quality; it does not substitute for our own threat model.

Key questions.

1. Is "developer logins" hard-disabled outside local/staging, or is production gating our responsibility via config? What is the default?
2. What is the exact authorization hook — a Gate, a policy, a config closure? Can we express "role X may impersonate role Y but never role Z" without patching?
3. Does impersonation write an audit event, and can we redirect it into our existing audit pipeline (or must we log around the package)?
4. For linked sub-accounts: does the package assume a specific schema (self-referential parent_id, pivot table), or does it read through a contract we implement?
5. How does it interact with 2FA, password confirmation middleware, and remember-me sessions?
6. Does the impersonated session restore cleanly on exit, including on session expiry mid-impersonation?
7. (new, prompted by 4.2.1) What is the search-resolver contract, what does it query by default, and does it respect our authorization scope — i.e. can we guarantee the developer-login search never returns users the operator is not permitted to become? Is the default query indexed, or a leading-wildcard LIKE scan over the users table?

Integration Approach

Stack fit. Requires Laravel + Filament v5 + Livewire. Before committing, verify the composer.json PHP and filament/filament constraints resolve against our pinned versions; Filament majors move fast and this package tracks v5 only. Verify our user model's guard is the panel's auth guard — impersonation across multiple guards is a common failure point. v4.2.1's docs change also implies the package's examples were historically written against PostgreSQL; confirm the search resolver behaves correctly under our production driver (MySQL collation semantics and SQLite differ meaningfully for case-insensitive matching).

Migration path. There is no meaningful data migration: the package is additive (config + its own migrations + a relationship on our user model). The migration that matters is behavioral, replacing whatever we do today — typically a bespoke "login as" controller, a laravel-impersonate dependency, or manual seeded dev accounts. Retire those in the same release, not after, or we ship two impersonation paths with different audit behavior. UPGRADE.md and CHANGELOG.md are maintained, so the 3→4 upgrade notes are a reasonable proxy for how breaking changes are communicated; read them, plus the 4.1.x/4.2.0 entries we have not yet reviewed, before pinning. v4.2.1 itself is non-breaking and requires no migration or config republish.

Compatibility. Test explicitly against: (a) tenant-aware panels with tenantless pages — the 4.0.4 bug class, untouched by this release; (b) panels mounted on a non-default path or domain; (c) custom user models with soft deletes and non-integer keys — these now matter twice, since the developer-login search resolver queries that model directly; (d) our 2FA/password-confirmation middleware ordering; (e) the session driver in production (database/Redis) for impersonation state; (f) our database driver, for case-insensitive search behavior.

Sequencing.

1. Spike (non-prod). Install on a throwaway panel, exercise all three features, capture actual behavior vs. documented behavior. Output: threat model and authorization design. Explicitly inspect the developer-login search resolver's query and scope — this is now a named deliverable, not incidental.
2. Security gate. Written decision on who can impersonate whom, mandatory audit logging, dev-login environment guard, resolver scope limits, and a documented break-glass path. This gate blocks everything else.
3. Schema + model. Add the linked-account relationship, run additive migrations, backfill only if we have real sub-account data.
4. Internal-only rollout. Enable impersonation for a named internal admin group behind a feature flag; run for two weeks watching audit volume and support tickets.
5. Widen. Enable linked sub-accounts (customer-facing, higher stakes) only after the escalation flow is verified end-to-end with 2FA.
6. Dev logins last, scoped strictly to non-production environments, with the search resolver reviewed alongside the environment guard. The v4.2.1 UI polish is not a reason to move this step earlier.

Operational Impact

Maintenance. Ongoing cost is low but not zero: this package touches auth, which means every Filament major and every Laravel auth change is a potential break. Budget a review per Filament upgrade, and note that the package is now shipping minor releases at a visible cadence (4.0.4 → 4.2.1), so "review the changelog" is a recurring task rather than a one-off. MIT license plus a small, well-structured codebase means forking is a realistic contingency — capture the fork decision criteria now (e.g., "no upstream fix in 30 days for a severity-1 auth issue"). The maintainer's CI discipline (health checks on every push, weekly published-score gate, pinned actions) and the steady trickle of small, clean releases suggest upstream fixes land promptly, which is the main mitigant to bus factor.

Support. Community-only. No vendor SLA, no paid tier, no guaranteed response. We own triage. Staff a named owner for this dependency — impersonation is not a package you let drift unowned. Cosmetic releases like 4.2.1 should not consume that owner's review budget beyond a changelog read; save the depth for anything touching authorization, routing, or session handling.

Scaling. Core switching performance is a non-issue: switching is a low-frequency administrative action with a couple of indexed lookups. The developer-login search introduced in this release adds a second, smaller query pattern — a user-table search on menu open. Volume is negligible, but the query shape is not: if the resolver does a leading-wildcard match on name/email, it is an unindexed scan and, more importantly, an enumeration endpoint. Scope and index it deliberately. Other real scaling concerns are (a) audit log volume if impersonation becomes a routine support motion — cap and retain deliberately; (b) concurrent impersonated sessions during incident response, which is fine but must be visible in the audit trail; (c) linked-account queries against large tenant tables — confirm an index on the parent/child key.

Failure modes to instrument.

• Route-generation failures in tenant panels (Missing parameter: tenant) — the known 4.0.4 class, unchanged in 4.2.1. Add a smoke test per panel covering tenantless pages, and alert on the exception string.
• Impersonation session not cleared (stale "you are viewing as" state, or an admin stuck in a customer account). Alert on session-state errors; document the exit path.
• Dev login reachable in production if the environment guard is misconfigured. Add a CI/deploy-time assertion that the feature is off in prod, not just a config review.
• Search resolver returning out-of-scope users — the developer-login search is an enumeration surface; a resolver that returns the whole user table hands an operator a directory they were never meant to see. Assert the resolver's scope in a test, not in a config comment.
• Migrations not run after a package upgrade — standard deploy gate covers this.
• Silent authorization drift — someone widens the impersonation allow-list or the search-resolver scope without review. Treat both as security-sensitive code requiring the same review as a policy change.

Ramp-up. Small for engineering (hours to a working spike), moderate for security and support (days to a defensible policy, runbook, and audit integration). The gating cost is not the package — it is deciding and documenting who is allowed to become someone else, and being able to prove it afterwards.