- How do I install afsakar/filament-otp-login in a Laravel Filament application?
- Install it with Composer, publish any config and migration files the package ships, then point your panel's login page at the package's login class in the panel provider. Expect a small migration if OTP records are persisted, plus configuration for code length, TTL and delivery channel. Because this is an authentication dependency from a low-velocity maintainer, pin the exact version in composer.json rather than using a caret range. Run the install in a sandbox branch first so you can confirm the login page renders before touching real admin accounts.
- Does filament-otp-login support Filament v3 or Filament v4?
- Compatibility depends entirely on the Filament constraint declared in the package's composer.json, so check that before anything else. Filament's panel configuration API and auth page contracts have changed between v3 and v4, and packages that subclass the Login page are the most likely to break across a major bump. If the constraint is open-ended, treat an upgrade as untested and verify the login page and OTP round-trip yourself on your pinned Filament version.
- Is this package passwordless login or a second factor on top of a password?
- The package is described as passwordless sign-in via temporary codes, which means the mail or SMS channel becomes the sole authentication factor if you replace password login. That is a materially different risk profile from password plus TOTP, especially for privileged admin panels. Check the source and config for a flag that lets password login stay enabled, and until you have confirmed it, do not cut over your primary admin login.
- Which delivery channels does filament-otp-login support — email only or SMS too?
- Verify this in the source rather than assuming; most packages of this size ship mail delivery in-box and leave SMS to a custom driver. If your business requires SMS, confirm an extension point exists for swapping the notifier before you commit to the package. If no such hook exists, you are looking at forking or writing your own delivery layer.
- How do I configure OTP length, expiry time and code format?
- Configuration is normally handled through a published config file covering code length, TTL and the delivery channel, all of which you should tune before going live. Keep the TTL short and the code length long enough to resist guessing if you have no hard attempt cap. Read the config file against the source that consumes it, because a documented option that is not actually enforced is a common failure mode in small auth packages.
- Are OTP codes hashed at rest, and is there brute-force protection?
- These are the two things to audit first: whether codes are stored hashed or in plaintext, and whether there is a hard attempt counter with lockout per user and per IP. Also check for constant-time comparison, single-use enforcement, replay protection after expiry, and rate limiting on both the send and verify endpoints. Regardless of what the package provides, add edge rate limiting on those routes in your own middleware. The codebase is small enough that a one-day source audit is realistic and worth doing before staging.
- Does it work with multiple Filament panels, multiple guards and tenant-scoped panels?
- Login pages are wired per panel, so multi-panel setups usually work, but guard and broker resolution is where small packages tend to assume defaults. Tenant-scoped panels add another layer, since the user lookup has to respect the current tenant and not leak codes across tenants. Test each panel configuration explicitly rather than assuming one working panel means all of them do.
- Can I use a custom notifier or SMS driver to send the OTP code?
- Look for a config key or interface you can bind to swap the notification class; if the package sends codes through a hard-coded notification, a custom channel becomes a fork. Confirm the extension point exists before committing, since SMS is the usual reason teams need one. Also check whether delivery is queued, because an OTP sent through a backed-up queue worker will expire before it arrives.
- Is afsakar/filament-otp-login safe to use for production admin authentication?
- It is an authentication surface maintained by a single developer with modest adoption, so treat it as untrusted code until you have read it. Also verify the release metadata yourself, since the stated last release date looks implausible and may be a mirror artifact rather than a real tag. If you proceed, roll it out behind a feature flag for a small internal cohort, keep a break-glass password or SSO path for super-admins for at least one release cycle, and confirm SPF, DKIM and DMARC on your sending domain. An OTP-only login plus an email outage equals a full admin lockout.
- How do I test OTP login in my Laravel test suite?
- Fake the mail or notification channel, trigger the send endpoint, assert a code was generated, then complete the verify flow with that code. Add negative tests for expired codes, wrong codes, exceeded attempt limits and codes replayed after successful use, because those are the cases that matter in production. If the package stores codes in a table, assert in the database that the stored value is not the plaintext code. For alternatives, compare against Filament's own authentication and MFA features where available, Laravel Fortify's TOTP support, or a maintained 2FA package, since each avoids adding a single-maintainer auth dependency.