Filament Password Confirmation Laravel Package

Getting Started

Re-entry confirmation for sensitive Filament actions: the package gives you a password field you can drop into an action's modal form (or any Livewire form) that validates the submitted value against the currently authenticated user's hashed password.

1. composer require juliomotol/filament-password-confirmation
2. Confirm the Filament constraint in composer.json matches your app (this package rides on Filament's form/action APIs — check before bumping Filament majors).
3. Nothing to publish or register for the common case; it's a form component, not a panel plugin with config.
4. Start with the README's action example, then wire up your first use case: a destructive DeleteAction or a "revoke API token" action that currently only uses ->requiresConfirmation().

use Filament\Actions\Action;

Action::make('deleteAccount')
    ->requiresConfirmation()
    ->form([
        // exact FQCN per README — verify the import before copying
        PasswordConfirmation::make('password'),
    ])
    ->action(fn () => $this->account->delete()),

The mental model: this replaces Laravel's password.confirm middleware for the action layer, where middleware can't reach.

Implementation Patterns

Action modal form (the primary pattern). Because the field lives in the action's form(), Filament's existing modal lifecycle handles validation, error display, and reset. No custom redirect-to-confirm-page flow.

Centralise it in a reusable action/trait. Once you're gating three or four actions, stop duplicating the schema:

trait ConfirmsPassword
{
    protected function confirmPasswordField(): array
    {
        return [PasswordConfirmation::make('password')->revealable()];
    }
}

Pair with ->visible() / policy checks, not instead of them. Password confirmation is a "are you still the person at the keyboard" check, not authorisation. Keep ->authorize()/policies doing the permission work; the field answers a different question.

Custom page or standalone Livewire form. Anywhere Filament renders a schema (Filament\Forms\Concerns\InteractsWithForms), the field works the same — useful for "danger zone" settings pages that submit several changes at once.

revealable() (new in v1.2.0). Adds the eye toggle so users can check what they typed. Use it on confirmation fields where typo-driven failures are common (long passphrases, password-manager paste failures). Leave it off if you have a policy against plaintext display on shared screens — it's opt-in, so existing fields are unchanged by the upgrade.

Testing. Drive it through Filament's Livewire test helpers so you cover both the reject and accept paths:

livewire(ListUsers::class)
    ->callTableAction('delete', $user)
    ->fillForm(['password' => 'wrong-password'])
    ->callMountedAction()
    ->assertHasFormErrors(['password']);

// and the success path
->fillForm(['password' => 'correct-password'])
->callMountedAction()
->assertHasNoFormErrors();

Gotchas and Tips

• Guard mismatch. Validation runs against the authenticated user for the active guard. In multi-guard panels (admin + customer), confirm which guard the field resolves — a passing login on one guard can still fail confirmation if the component reads another.
• Passwordless users. SSO/social-login accounts have no password hash to match. Guard the action's visibility (->visible(fn () => filled(auth()->user()->password))) or these users get a permanently unusable action.
• No throttling included. The field validates; it doesn't rate-limit. An unlocked screen is a brute-force surface — pair with Laravel's RateLimiter/throttle on the action if that matters for your threat model.
• Error messaging. Keep the validation message generic ("These credentials do not match our records") so a failure doesn't distinguish "wrong password" from other states.
• Modal state. Filament resets action forms between opens by default; if you've customised ->modalHeading() or persisted form state, verify the password field isn't prefilled from a previous invocation.
• revealable() is cosmetic only (v1.2.0). It flips the input type to text; hashing, validation, and error behaviour are untouched. Don't treat it as a security setting.
• Low-risk release to take. v1.2.0 is a feature addition plus a typo fix and a CI-only Dependabot bump (fetch-metadata) — no breaking changes, no migrations, no config changes. Safe patch from v1.1.0.
• Extension point. If the built-in behaviour doesn't fit (custom guard, custom message, extra ->rules()), subclass the field rather than forking the package — it's a single form component, so overriding is cheap.
• Debugging failures. If a correct password is rejected, check Hash::check() semantics first: the stored hash's driver must match your HASH_DRIVER, and users imported with a different algorithm will fail silently.