Reset Password token in Email link does not match in database table

@neilstee , yes, I understand that token in db is encrypted and token in link is not. They are not the same after I encrypt the token as what you said.

Actually I tried with bcrypt('abc'); in both of my blade files, they give different encrypted value.

I did the following and it says not same (comparing the db value with link in my controller reset function),

$pass = DB::table('password_resets')->where('email', '[email protected]')->value('token');
if(Hash::check($request['token'], $pass)) {
    dd('same');
 } else {
    dd('not same');
 }

@neilstee this wouldn't work. Runinng Hash::make($token) on same $token twice will produce different hash each time. You do have to use Hash::check($token, $hash_from_db) to test it's matching.

Sorry, I will do that.

Updated: Already format the code, anyone can help???

Sorry, let me restructure my questions.

I try to create the reset password feature by following Laravel 8 example. I created 2 views, one for user to enter their email and one for entering their password and confirmed password. The feature works fine until user press the button to submit the new password. The validation shows "This password reset token is invalid".

So I tried to do comparison on the token in the link and encrypted token in database by using code in my first example (Hash::check). The result is they are not the same.

I did an experiment by doing bcrypt('abc') on both of the views, they gave different output. So obviously every time bcrypting the same string will give different results.

I wonder how should I tackle this problem. Or where should I start investigating?

Sorry, maybe I am a bit confuse on encrypt and bcrypt. I meant bcrypt instead of encrypt.

You are right. The email is the one sent out to user when user click confirm when they enter their email address in order to request for reset password link. User will read this email and click the link to go to the reset password page and provide new password.

I am getting “password reset token is invalid” when user side tries to submit the new password.

Is there a way to verify that the token sent by link is the same token hashed in database?

Anyone can help?

Yes of course, it's actually from Laravel's PasswordBroker::contract, the default implementation of this contract for laravel breeze does not sync the token and the hashed token in the db by default,

The magic all happens in your PasswordResetLinkController when you call the sendResetLink method of the Password Facade

look for the code below and examine it

 $status = Password::sendResetLink(
            $request->only('email')
        );

this method is supports an optional callback as a second param; the callback receives the $user and generated $token for the password reset operation. I guess laravel expects us to utilize this optional callback to have full control of our password reset process when using laravel breeze. However, since its laravel, we are supposed to be up and running with the default configuration from laravel. But this is not so with laravel breeze. I can't say anything about Fortify and Jetstream. However, there is a workaround and its pretty easy...

I had the same issue and this is how I solved it I had to update my 'vendor\laravel\framework\src\Illuminate\Auth\Passwords\PasswordBroker.php' file In your ('vendor\laravel\framework\src\Illuminate\Auth\Passwords\PasswordBroker.php')

Step 1: Look for this line of code

$user->sendPasswordResetNotification($token); 

this is the line that sends the password reset notification email with the raw generated $token to the user. Hence, what we need to do is inject our custom code that verifies that the hashed value of the $token is the same as the one in the password_resets table; this way we would have already synced the two tokens (in db and email) Hence, immediately the email has been sent with the $token, you can grab that $token and use it for your validation

My approach was to update my db migration on the passwords_resets table and I then created a new column which stored the raw $token, this way it was easy for me to validate both (hashed and raw ) tokens from the db using eloquent. here is my code

Migration

public function up()
    {
        Schema::create('password_resets', function (Blueprint $table) {
            $table->string('email')->index();
            $table->string('token');
			//this is the raw_url_token column i added
            $table->string('raw_url_token')->nullable();
            $table->timestamp('created_at')->nullable();
        });
    }

step 2: I updated my 'vendor\laravel\framework\src\Illuminate\Auth\Passwords\PasswordBroker.php'

immediately after this line : $user->sendPasswordResetNotification($token); you place your custom code, just like i did mine

$user->sendPasswordResetNotification($token);

            // update the password_resets table using custom code
            
            DB::table('password_resets')
                ->updateOrInsert(
                    ['email' => $user->email],
                    [
                        // the raw token sent to the user's email as seen in the url
                        'raw_url_token' => $token,
                        // the token that will be saved in the db for validation
                        'token' => Hash::make($token)
                     ]
                );

this way anytime a password reset link is activated, the generated $token is consistent across both the db the email, because we are in fact working with what was sent to the user in his email(raw_url_token) and hashing it to restore it in another column (token).

and that's all.. Hope it helps you ... #Peace

A better alternative would be to copy that custom code we wrote and put it in a callback that should be used as a second parameter to the sendPasswordResetNotification() in your

App\Http\Controllers\Auth\PasswordResetLinkController file

See below:

         $status = Password::sendResetLink(
            $request->only('email'),
            fn ($user, $token) =>
                (DB::table('password_resets')
                    ->updateOrInsert(
                        ['email' => $user->email],
                        [
                            // the raw token sent to the user's email as seen in the url
                            'raw_url_token' => $token,
                            // the token that will be saved in the db for validation
                            'token' => Hash::make($token)
                        ]
                    ))  
                    ? $user->sendPasswordResetNotification($token) 
                    : null
        );

The hard-coded option is not the best solution because it will disappear after update, so with this new way of using a callback, we are sure that the code will function even after subsequent updates. Also from this code, it is evident that the task of sending the mail comes last in the source order, and the mailing of the user is dependent on the db transaction or query.