Filament Login Shortcut Laravel Package

Getting Started

Requirements: Laravel with Filament v4.7+ or v5.2+. As of v1.0.2 this is enforced at the Composer level — older Filament versions are rejected during composer update rather than exploding at render time.

1. Install:

   composer require outatime-io/filament-login-shortcut
   

2. Publish and review the config:

   php artisan vendor:publish --tag="filament-login-shortcut-config"
   

3. Register the plugin on the panel(s) you want it active on — typically your local / staging panel provider, not your production one:

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

Where to look first: the published config file. Everything meaningful about this package is opt-in behaviour — which users are offered, whether the shortcut is enabled at all, and how the shortcut is labelled. Skim the config before touching the panel provider; it answers most "why isn't it showing up?" questions.

First use case: seeding a handful of role-specific dev users ([email protected], [email protected], a customer with an odd subscription state) and then skipping the login form entirely when switching between them while building a feature. The package renders a callout on the Filament login screen — that callout is the filament::callout component referenced in the v1.0.2 fix — so your first smoke test is: load /admin/login on local and confirm the callout appears with your seeded accounts.

Implementation Patterns

Environment-gated registration. The single most important pattern is registering the plugin conditionally, so a stray deploy can't expose one-click login:

->plugin(
    LoginShortcutPlugin::make()
        ->enabled(app()->environment(['local', 'staging']))
)

Prefer this over relying on a config flag alone — belt and braces, and it makes the intent obvious to reviewers.

Deterministic seeders. Give the shortcut a stable, named cast of characters. A dedicated DevUserSeeder that truncates and recreates the same emails on every migrate:fresh --seed means your muscle memory for "the admin one" survives a database reset. Random faker emails defeat the purpose.

Multiple panels, multiple registrations. If you have an admin panel and an app panel with different user models or guards, register the plugin on each provider separately and keep the offered user lists distinct. Filament's multi-panel setups will happily let you offer a user that can't authenticate against the current guard — see Gotchas.

QA and demo hand-off. Staging environments with stakeholder demos are the sweet spot: hand a reviewer a URL and let them jump between a free-tier account and a paid-tier account without credentials in Slack. Pair it with the environment gate above so the demo conveniences never leak to prod.

Testing flows. For Pest/PHPUnit browser tests and manual acceptance passes, the shortcut removes the "log in, navigate, log out, log in as someone else" tax. Use it while authoring tests, but still keep explicit actingAs() calls in the suite itself — the UI shortcut should not become a test dependency.

Pair it with a reset seam. If your feature work mutates user state (roles, subscriptions, onboarding flags), add an artisan command or seeder you can re-run to restore a known-good user. The shortcut gets you in fast; without a reset it also gets you into a broken account fast.

Gotchas and Tips

The v1.0.2 constraint is real, not cosmetic. If your composer.json pins Filament to something below 4.7/5.2, composer update will now refuse the install. That's the intended behaviour — the alternative (v1.0.1) is a package that installs cleanly and then throws Unable to locate a class or view for component [filament::callout] the moment someone opens the login page, which is a far worse failure mode because it hits the login screen itself. Upgrade Filament first, then bump this package.

Watch your lockfile in CI. Because the floor moved, a Dependabot/Renovate PR that bumps this package without bumping Filament will fail at composer update rather than in your test suite. That's good — but make sure your CI runs composer validate / a dry-run install so the failure is attributed to the dependency graph and not misread as a flaky build.

Config caching is the usual suspect. After publishing the config or toggling the plugin, run php artisan config:clear (and filament:optimize-clear if you've cached components). "The shortcut disappeared" is almost always a stale cached config in a container that was built before the publish.

Guard and model mismatch. The shortcut logs a user in against the panel's guard. If you offer a user from a different model or guard than the panel authenticates with, you'll get a silent redirect back to login rather than an error. Keep the offered set scoped to the panel's own auth provider.

Environment leakage. The plugin registering itself on a panel is not the same as the panel being safe. Double-check APP_ENV on every deploy target — a staging config copied to a production host is the classic way this becomes an incident. Consider a hard abort_unless(app()->isLocal() || app()->environment('staging'), 404)-style guard in the panel provider if your deploy topology is messy.

Don't let it reach a real customer. If the package offers "any user matching a query" rather than an explicit list, restrict it to explicitly whitelisted emails. An enumeration-shaped shortcut on a misconfigured environment is an account-takeover primitive, not a convenience.

Debugging an empty callout. If the component renders but shows nothing, the offered-users list is resolving empty — check the config values and that your seeder actually ran against the same database connection the panel uses. If the whole login page 500s on filament::callout, you're on the pre-4.7/5.2 Filament this release exists to exclude.

Extension points. Behaviour lives in the plugin object and the config, so prefer fluent calls on LoginShortcutPlugin::make() in the panel provider over editing vendor files; keep the published config as the single source of truth for which accounts are offered, and let the provider own the environment gating. That split makes the "is this safe in prod?" review a two-line diff instead of a hunt.