Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

jbloomstrom's avatar

Use custom ConfirmPassword hook for Inertia CurrentUserController@destroy password validation

Background:

I opened this as an issue on the Jetstream repo, but they said it would be better to ask somewhere else.

  • Jetstream (Inertia)
  • User Provider: Active Directory via LdapRecord package

Problem:

I'm using a non-laravel user provider (Active Directory via LdapRecord package) and therefore need a custom hook for confirming passwords:

// AuthServiceProvider
public function boot() 
{
    $this->registerPolicies();

    // custom hook for confirming passwords
    Fortify::confirmPasswordsUsing(function($user, $password) {
        return Auth::validate([
            'mail' => $user->email,
            'password' => $password
        ]);
    });
}

This works great for confirming passwords, but I found when the password is confirmed before account deletion the @destroy method on Interia's CurrentUserController uses the Validator password rule and not the custom hook. This causes validation to fail with the message the password is incorrect.

// Laravel\Jetstream\Http\Controllers\Inertia\CurrentUserController
public function destroy(Request $request, StatefulGuard $auth)
{
    // this does not use the custom hook 
    // and the validation fails.
    $request->validate([
        'password' => 'required|string|password',
    ]);

   ...
}

I found a way to solve the issue, but it feels a little gross. I can substitute my own validator in AppServiceProvider by passing it in via the Validator@resolver method.

// AppServiceProvider
    Validator::resolver( function($translator, $data, $rules, $messages, $customAttributes) {
        return new App\Validation\Validator($translator, $data, $rules, $messages, $customAttributes);
    });

Then I can override the @validateCurrentPassword method on my custom validator class

// App\Validation\Validator
protected function validateCurrentPassword($attribute, $password, $parameters)
{
    Log::debug("Using custom validator");

    return app(ConfirmPassword::class)(
        Auth::guard(), Auth::user(), $password
    );
}

It seems like there should be some consistency to how passwords are confirmed. Why does it allow a custom hook for other areas but then uses Laravel's validation rule for account deletion? Ideally any password confirmation should conform to a standard. I'm tempted to submit a PR to the repo, but I doubt it will get any traction unless others chime in with support.

Is there a better way to substitute the password validation rule to make it use a different method? Has anyone else run into this?

Thanks, -Jeremy

0 likes
12 replies
EnterUsername's avatar

Create a custom rule instead php artisan make:rule PasswordRule

then use it in the validator

  $request->validate([
        'password' => ['required' , new \App\Rules\PasswordRule],
    ]);

jbloomstrom's avatar

@enterusername Thanks for the reply, but this code isn't in my controller it's in JetStream's controller. I can't change the controller action to use a custom rule.

martinbean's avatar

@jbloomstrom Don’t tag people to summon them to your question. We’re not on call for you. People will answer if they want to.

I hadn’t looked at this thread because it haven’t work much with Inertia.

martinbean's avatar

@jbloomstrom It is. The “attitude” is because I don’t work here, I don’t appreciate being “summoned” to reply to a thread. I reply to threads as and when I want to. I’m not obligated to reply to you or anyone else.

Like I say, I don’t really work with Inertia so hadn’t even bothered to read this thread before you decided I work for you and that I’m on-call to answer questions at your beck and call.

So yeah, if you’re going to be rude to me don’t be surprised I’m being rude back.

2 likes
jbloomstrom's avatar

@martinbean I apologize, I honestly wasn't trying to be rude. I certainly didn't mean to imply that you work here or that you or anyone else is under any obligation to provide assistance. I'll stop tagging people.

Snapey's avatar

Could you write your own class that extends Inertia\CurrentUserController but implements your own destroy method?

jbloomstrom's avatar
jbloomstrom
OP
Best Answer
Level 50

@snapey Thanks for the suggestion. I dug into the code a bit more and found that Inertia's OtherBrowserSessionsController.php has the same issue. I ended up submitting a PR for this and it was merged this morning.

1 like

Please or to participate in this conversation.