These credentials do not match our records.
I tried logging in with correct credentials and this is what I encounter. My friend is using windows and we pulled from master and did all the composer and npm without an error and imported the same database. He was able to login but in my case I got 'These credentials do not match our records.'. I even try to change it's password but still got the same error
17 Replies
I use this seeder to change password and I double check if the password is really password123 and still have the same error 'These credentials do not match our records.'
hey @makmak did you find out what was happening here. I have the same issue. Reseeded a fresh install and many users reporting These credentials do not match our records. Even though the password is correct
maybe try to make another user and check if that works?
I have been dealing with this issue intermittently for a while and have been unable to figure out what's causing it. My application is in production and users will initially be able to log in and then the next time they go to log in they'll get this message.
If I clear out the email_verified_at field in the database and resend the invite, it works again, but I really need to get this figured out. Did you have any luck?
What's your APP_ENV value?
Last time I had this problem I had it set to production instead of local.
Also check if in your User model you have the function
Are you using uuid for the user?
no uuid, just standard bigint. The APP_ENV is not the issue, nor is the canAccessPanel method.
The only thing I can think of is that somehow the password is getting hashed twice somewhere, but I'm not doing anything super custom on the login side. It's just standard filament. The latest user sent me their password and after hashing it and comparing it to the stored value in the DB, they were not the same. I updated it to the hashed value of what he says his password is and now it's working fine.
I thought it had something to do with the remember token for a minute, because that seemed to be a common factor, until this user today, he didn't have that token set. The remember functionality doesn't seem to be working at all, so there may be something I've not implemented correctly.
odd. wonder if it has something to do with laravel 11 automatically casting the passowrd as 'hashed'
i'm on laravel 10.10
then i definitely don't know. lol.
🤷♂️
nothing else is coming to mind out of the box that would cause the password to get hashed twice.
ok, I'll keep monitoring and maybe I can figure out the common denominator.
are you using breeze or jetstream?
the intermittentcy is just really odd.