Filament Renew Password Laravel Package

Technical Evaluation

Architecture fit. mei-labs/filament-renew-password is a narrow, single-responsibility plugin: it adds password expiry and forced renewal to Filament panels. It slots into the existing Laravel/Filament authentication stack rather than introducing a parallel identity system, which is the right architectural shape for the requirement "admin users must rotate passwords on a schedule or on first login." The design is deliberately config-driven (expiry days, redirect route, force-on-first-login toggle) and exposes a small number of seams — the published config, the migration, the plugin registration in a panel provider, and an overridable renewal page class. From a TPM perspective, that is a good integration surface: it means most policy changes are configuration and test work, not engineering work. It is not an IAM platform and should never be scoped as one.

Integration feasibility. Feasible for an existing Filament 3 panel with modest effort. The install is standard Composer plus two vendor:publish calls and a migration; wiring is a single ->plugin(RenewPasswordPlugin::make()) line in the relevant panel provider. The realistic effort is not installation but the surrounding work: backfilling the new user columns, deciding null semantics, adding pre-expiry notifications, and writing the three tests that prove the behaviour (expired redirects, valid does not, post-renewal does not bounce again). Call it a small spike plus a sprint-sized hardening effort, not a drop-in toggle.

Technical risk. The dominant risks are behavioural, not architectural:

• Null-backfill ambiguity. Existing rows get NULL in password_changed_at after migration. Depending on how the package interprets null, that is either a silent no-op (nobody is ever prompted — false sense of compliance) or a mass lockout on deploy. This is the single highest-severity risk and a genuine release gate.
• Maintenance signal is weak. Zero stars, a single minor release in March 2024, and a changelog that is a bare compare link with no prose. There is no evidence of a maintainer roadmap, security-response process, or Filament-version support policy. For an access-control control, that is a real vendor-risk conversation, not a footnote.
• Enforcement gaps. Middleware-based enforcement on Filament pages does not automatically cover Livewire update endpoints, Sanctum token APIs, or Filament impersonation. A user can be "expired" and still partially interact if those paths are unguarded. This must be explicitly closed or explicitly accepted.
• Redirect-loop fragility. The middleware whitelists the renewal route by name/path. Custom route prefixes, localised panel paths, or global middleware registration produce ERR_TOO_MANY_REDIRECTS after login.
• Validation divergence. If the package's renewal form does not use the same Password::defaults() ruleset as registration/login, users hit inconsistent acceptance. Low severity, high UX noise.

Key questions to resolve before committing.

1. What are the null semantics for password_changed_at, and what is our deliberate backfill policy (likely users.created_at for graceful ramp)?
2. Which panels does this apply to, and do admin and customer panels need different expiry windows (30 vs 180 days)?
3. Are token-authenticated APIs and impersonation in scope? If yes, this package only solves the panel half.
4. What is our supported Filament version, and has this been verified against it in staging?
5. Who owns the risk if the package goes unmaintained — do we fork it, pin it, or wrap it?

Integration Approach

Stack fit. Laravel + Filament 3, Livewire-driven panel, standard users authenticatable. The package assumes it can read and write renewal state on the user model (via a trait) and that it can intercept authenticated panel requests. If your authenticatable is non-standard — multi-tenant user models, separate admin and customer models, or an external IdP-backed login — fit degrades quickly and the build-vs-buy calculus flips toward custom.

Migration path. Ordered and non-negotiable:

1. composer require mei-labs/filament-renew-password and pin (^2.1 preferred over ^2.0 to pick up fixes without surprise minors).
2. Publish config and migration; inspect the migration to confirm exactly which columns land on users.
3. Run migration on a staging copy with production-shaped data, then decide and execute the backfill.
4. Register the plugin in the panel provider, not a shared service provider, and place its middleware after Authenticate::class and before resource routes.
5. Clear Filament's cached panel config (php artisan filament:optimize-clear) and rebuild config:cache in every environment.
6. Exercise the flow with one test user before widening.

Compatibility. Treat v2.1.0 as an incremental, semver-minor upgrade — no breaking changes implied — but verify against your Filament version explicitly, because the changelog provides no compatibility statement. The main compatibility hazards are Livewire route interception, localised/custom panel paths, and any vendor-file override (which is also the most likely thing to break on a future minor).

Sequencing for delivery. Ship in three slices rather than one: (a) schema + backfill + tests behind a disabled flag; (b) enforcement enabled for the admin panel only, with pre-expiry notifications implemented in our code as a scheduled command rather than waiting on the package; (c) hardening — Auth::logoutOtherDevices(), remember-token rotation, API/impersonation coverage — as a follow-up. Keep policy knobs in config, keep validation in one Password::defaults() definition, and extend the package's renewal page class rather than editing vendor files.

Operational Impact

Maintenance. Low ongoing code maintenance, moderate ongoing ownership burden. The package is small and the extension points are stable, but the lack of maintainer activity means we should assume we may need to fork or vendor a patch. Budget a named owner and a periodic compatibility check against Filament releases. Password-history tables, if used, need scheduled pruning with a retention window at least as long as the "no reuse last N" setting, or reuse prevention silently degrades.

Support. Support load will come from users, not the package: "why am I being asked to change my password," expired-session confusion after renewal, and impersonation edge cases where an admin is trapped behind an expired user's renewal wall. Pre-empt this with comms (warn users before expiry) and an admin runbook covering ERR_TOO_MANY_REDIRECTS, stale config cache, and how to unblock a single user.

Scaling. Enforcement adds one authenticated-request check per panel request — negligible. The real scale concern is the backfill and any scheduled query that scans users nearing expiry; index the relevant timestamp column and keep the notification query bounded. Multi-tenant or per-panel policy variation is handled by instantiating the plugin per panel with different config, which is clean but must be tested per panel.

Failure modes to instrument. (1) Mass lockout from a null or epoch backfill — detect via a spike in renewal-page traffic post-deploy. (2) Silent no-op where nobody is ever prompted — detect via a dashboard of "users past threshold who have not renewed." (3) Redirect loop after a route or panel-path change. (4) Livewire update requests succeeding after expiry. (5) Config cache staleness making a policy change appear broken. (6) Divergent password validation producing rejection-at-login for a password accepted at renewal.

Ramp-up. Fast for a Laravel-fluent engineer — half a day to read the config, migration, and plugin class, then a day to wire and test. The slower part is organisational: agreeing the policy (expiry window per panel, first-login enforcement, notification lead time), doing the backfill safely, and securing stakeholder sign-off that this is an access-hygiene control and not a substitute for SSO, MFA, SCIM, or audit logging. Position it that way to security and compliance stakeholders and the scope conversation stays short.