"Undefined index: token" error on password reset.

maybe like this?

 '_token' => 'required',

Yeah, that's exactly what happened.

"Undefined index: token"

It will only work if I remove the token required validation. Otherwise, it will not pass as apparently the token doesn't validate.

View the html source of that reset password page after it's rendered in the browser. Does the token fields value match the one in the password_resets db table? Is there a value for the token in both places?

@Cronix

They are obviously different.

I'm assuming you're referring to this?

https://laravel.test/password/reset/ced8d44650cd6fedbd5d1642fe2e3cf7e6f947d989df4d98c762500a0c4e76ff

<input type="hidden" name="_token" value="y8TS4wSU3W6ujiTW27Lw7MjxHLivn1XUOuPCfwrM"> 

No, one is the password reset token (in the url) and the other is the csrf token (the input). Those should be different

Did you look in your password_resets database table? Is there a ced8d44650cd6fedbd5d1642fe2e3cf7e6f947d989df4d98c762500a0c4e76ff value for the token for that users email?

Ah, ok my bad and yes, they're different

From DB

$2y$10$p6N7vmA2AoFW2OSQaHYr7.cKZOfV3oFLf/wynO4dEJQ5E8ZDrLU5K

Token from email

06e53e36628590038b8b8fdb2f0315bedea2612a6349be3098bb1162fa107a5a

That's the issue obviously. I don't know what would cause it though. I haven't had that problem with the default password reset, so never really had to troubleshoot it.

Yeah, me too. I have no idea why the token sent to email is different from the one in the database. I can only concur that they are in different format.

I'm trying to figure out whether the email is sent first or the token is first created and stored in the database and an email is sent.

I didn't have this problem in L5.2.

@yansusanto @Cronix the password reset token is hashed equal to a password. So it is correct that your password reset token in your url is not in the password_reset database table.

This will return true:

\Hash::check(
    '06e53e36628590038b8b8fdb2f0315bedea2612a6349be3098bb1162fa107a5a',
    '$2y$10$p6N7vmA2AoFW2OSQaHYr7.cKZOfV3oFLf/wynO4dEJQ5E8ZDrLU5K'
)

laracasts note: if you have a value like $2 it is hidden within triple backticks code. Adding a backslash to does show it.

hidden dollar sign 2: 
visible dollar sign and 2: $2

@mrk

Is there a solution to that issue?

There is no issue, this is normal behavior. You have some other problem I guess but I do not know what. Do you have xDebug available? Try stepping through the code and you will figure out why you are being redirected.

Btw, you mentioned you didn't had this problem with L5.2. Are you currently running a fresh installation of L5.5 or L5.6? Or did you upgrade from L5.2 to a newer version? If I am not mistaken somewhere in between these versions the token is now passed as route parameter instead of a query parameter... not sure though if this causes this behavior.

@m-rk

Thanks for the input. No, it is a fresh installation of 5.6 and created auth with the built-in scaffolding.

I'm wondering why laravel isn't doing hash::checkby default or maybe it is?

Laravel is doing something like this:

1. You request a new token
2. Laravel creates a new token for you (40 random chars) and hashes that value and stores it in the password_reset together with the email address
3. Laravel sends an email with the 40 random chars to you.
4. You click on the link with the 40 random chars.
5. You enter your email and your new password
6. Laravel looks up the email in the database and checks the hashed token in the database with the 40 random chars in the url. If they match your password is changed. If they don't match you should see an error.

So even if you use an invalid token or a token of just 6 characters you end up at the password reset page. But it won't allow you to reset your password.

The question in your case is, what exactly is going wrong. I can't see that from here with this less information. You should be able to figure it out with xDebug and stepping through the code or with some old school die() in your code.

Thank you for the taking the time to explain it, @mr-k. I guess I have skip this and have a new install and see if the problem persists.