Filament Password Less Laravel Package

Getting Started

artmin96/filament-password-less swaps Filament's email+password login for a magic-link / one-time-login flow: the user enters their email, receives a signed link, and clicking it authenticates them into the panel.

Minimum path to first login:

1. composer require artmin96/filament-password-less — on Laravel 10 you need ^1.0.3; 1.0.2 and below do not declare Laravel 10 support.
2. Publish and review the config (config/filament-password-less.php) before touching anything else — expiry window, notification class, and the User model contract all live there.
3. Apply the package's trait/contract to your authenticatable model (App\Models\User) so it can issue and validate login tokens.
4. Register the plugin on the panel you want affected in the relevant PanelProvider (->plugin(...)), and remove/replace the default ->login() if the package expects to own that route.
5. Run migrations if the package ships a token table; php artisan migrate then php artisan filament:cache-components (or optimize:clear) so the panel picks up the new routes.

First meaningful use case: an internal admin panel or customer portal where you want to eliminate password storage/reset support load. Test it end-to-end with MAIL_MAILER=log locally so you can copy the link out of storage/logs/laravel.log.

Where to look first: the README's install section, then the published config file — the config is the de-facto documentation for token lifetime and notification customisation.

Implementation Patterns

Trait on the User model. Most integrations hinge on adding the package trait (plus, where required, implements for the contract) to User. Do this before registering the plugin, otherwise the panel boots a login page whose model can't mint tokens.

Per-panel opt-in. Register the plugin only on the panels you want passwordless. Keeping a second panel on stock ->login() is a clean way to retain a break-glass password route for staff while giving customers magic links.

Notification customisation. Subclass or swap the notification class in config to control the mail subject, branding, and queueing. Push it onto a queue (ShouldQueue) if you're on a slow SMTP relay — the request blocks on the send otherwise.

Integration with existing auth. If you already have password login, keep ->passwordReset() and the standard login as a fallback during rollout, then flip. If you're greenfield, don't seed passwords at all — it's the point of the package.

Testing. Use Notification::fake() and assert the magic-link notification was sent to the right user, then extract the signed URL from the notification to simulate the click. This is far more reliable than hitting the mail driver in CI.

Throttling. Wrap the request route in the package's rate limiter or your own throttle: middleware keyed on email + IP so the endpoint can't be used to spray inboxes.

Gotchas and Tips

• Version pinning is the whole story of 1.0.3. The release is a compatibility bump: Laravel 10 support arrived here. If you're on Laravel 10 and Composer resolved 1.0.2, you'd have hit an unresolvable or silently-wrong illuminate constraint — pin ^1.0.3 explicitly and run composer why-not artmin96/filament-password-less 1.0.3 if resolution fails. Correspondingly, check your Filament major (v2 vs v3) matches what the release supports; the notes only mention Laravel.
• Email enumeration. A login form that says "user not found" leaks your user base. Return the same success response regardless of whether the address exists.
• Expiry vs. mail latency. Short TTLs break corporate mail gateways that queue for minutes. Default to something generous (10–15 min) and log the token's expires_at when debugging "the link doesn't work".
• Single-use semantics. Confirm whether a token is invalidated on first use. If it isn't, a link forwarded or sitting in a shared inbox is a standing credential.
• Session/redirect weirdness. The signed URL often lands on a package route that redirects into the panel; if your panel has a custom ->path() or domain, the generated URL can point at the wrong host. Set APP_URL correctly and check url() output before blaming the package.
• Cached config in production. php artisan config:cache will freeze the package config; republish and re-cache after changing the notification class, or the swap silently won't apply.
• Don't reuse for API auth. This is a browser-session flow. Mobile/API clients should use Sanctum tokens; trying to bolt the magic link onto a JSON client usually ends in cross-domain cookie problems.
• Extension points worth knowing: the notification class (branding/queueing), the token model/table (custom TTL or extra claims), and the resolved login response — those three cover most real-world customisation without forking.