Filament Wildcard Login Laravel Package

Getting Started

• Install with composer require digifactory/filament-wildcard-login:^3.0. v3.0.0 targets Filament 5 only — if you are still on Filament 3/4, stay on the ^2.0 line until you upgrade your panel.
• Register the plugin on the panel(s) where you want it active, typically in app/Providers/Filament/AdminPanelProvider.php:

use DigiFactory\FilamentWildcardLogin\WildcardLoginPlugin;

public function panel(Panel $panel): Panel
{
    return $panel
        // ...
        ->plugin(WildcardLoginPlugin::make());
}

• Look first at the plugin's configure()/config file after publishing (php artisan vendor:publish --tag="filament-wildcard-login-config"). That is where the wildcard pattern(s) and the guard/model used for resolution live.
• First use case: a staging or internal panel where you want to sign in as any seeded user by typing a wildcard-friendly identifier (e.g. *@yourcompany.test) instead of remembering individual passwords. Confirm it works against your local User model before wiring it into a shared environment.

Implementation Patterns

• Environment gating is the primary pattern. Wrap registration in a check so the plugin never boots in production:

->plugin(
    WildcardLoginPlugin::make()
        ->visible(fn () => ! app()->isProduction())
)

Prefer controlling this at the panel-provider level rather than relying solely on the package's own config flag — defence in depth.

• Per-panel scoping. Register the plugin only on the panel you use for QA/support impersonation, not on customer-facing panels. Filament resolves login through the panel's guard, so a panel-scoped plugin keeps the blast radius small.

• Multi-guard / multi-model setups. If you have separate User and Admin models, register the plugin once per panel with the correct guard configured, and verify the wildcard resolves against the right provider — a mismatch silently falls through to normal login rather than erroring.

• Seeder-driven QA workflow. Pair the plugin with a deterministic seeder (php artisan migrate:fresh --seed) so wildcard logins always land on a known user. This makes it useful for demo environments and screenshot/PR review flows where reviewers need to see a specific role's UI.

• Test-suite integration. In Pest/PHPUnit feature tests, use the normal actingAs() helper rather than the wildcard path — the plugin is a developer convenience, not a test utility. Reserve live wildcard testing for a single smoke test that asserts the login form accepts the pattern.

• Behind a feature flag. If multiple developers share a staging box, gate the plugin behind a config flag (config('filament-wildcard-login.enabled')) read from .env, so it can be flipped per-environment without a deploy.

Gotchas and Tips

• v3.0.0 is a breaking upgrade. The only functional change in this release is the Filament 5 bump (plus Dependabot noise). Consequences:

  • composer update on a Filament 4 project will either fail resolution or force a Filament major upgrade. Pin ^2.0 until you have completed your Filament 5 migration.
  • Any custom view overrides or published config from v2 should be re-published and diffed — Filament 5 changed several schema/form APIs that login-form extensions touch.
  • If you extend or decorate the plugin class, re-check method signatures against the v3 source; there is no migration guide in the release notes, so read the v2.0.0...v3.0.0 diff.

• Silent auth failures. Wildcard logins that don't match typically behave like a normal failed credential check. If nothing happens, confirm: plugin is registered on the current panel, the guard matches the panel guard, and php artisan config:clear has been run — cached config is the most common cause of "the plugin isn't loading."

• config:cache in local/staging. Published config is cached; toggling the enable flag in .env requires a config:clear/config:cache cycle. Add it to your deploy script if you flip the flag per-environment.

• Session and rate limiting. Wildcard logins still pass through Filament's login throttling. Repeated QA logins can lock the form — either raise the throttle in local config or clear cache between runs when scripting logins.

• Never ship to production enabled. There is no compile-time guarantee; the safety comes entirely from your gating. Add a check to your deploy pipeline or a ProductionSafetyTest that asserts the plugin is not registered when app()->isProduction().

• Extension points. The plugin is thin by design. If you need richer behaviour (e.g. restrict wildcard matches to a specific role, or auto-provision a user), extend the plugin class or swap the underlying user-resolution callback rather than forking — the surface area is small enough that a subclass survives minor bumps, but re-verify on each Filament major.