Filament•10mo ago

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

makmakOP•10mo ago

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.'

makmakOP•10mo ago

acroninja•7mo ago

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

Tally•7mo ago

maybe try to make another user and check if that works?

 php artisan make:filament-user

 php artisan make:filament-user

Jon Mason•4mo ago

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?

Bruno Pereira•4mo ago

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

public function canAccessPanel(Panel $panel): bool
    {
        return true;
    }

public function canAccessPanel(Panel $panel): bool
    {
        return true;
    }

awcodes•4mo ago

Are you using uuid for the user?

Jon Mason•4mo ago

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.

awcodes•4mo ago

odd. wonder if it has something to do with laravel 11 automatically casting the passowrd as 'hashed'

Jon Mason•4mo ago

i'm on laravel 10.10

awcodes•4mo ago

then i definitely don't know. lol.

Jon Mason•4mo ago

🤷‍♂️

awcodes•4mo ago

nothing else is coming to mind out of the box that would cause the password to get hashed twice.

Jon Mason•4mo ago

ok, I'll keep monitoring and maybe I can figure out the common denominator.

awcodes•4mo ago

are you using breeze or jetstream? the intermittentcy is just really odd.

Jon Mason•4mo ago

that's what has me puzzled. I'm not using either of those. Just out-of-the-box filament. well I say that, I do have a different setup in that I create the user account and send them an email. It's not an app where they can register themselves. So I have internal users (work for me at my company) and external users. I don't recall having this issue on any internal users. I have an Authenticate middleware for internal users and an AuthenticateClient middleware for external users. Here's that code, is there anything about it that looks suspect? I just don't understand why it would be so intermittent.

class AuthenticateClient extends Middleware
{
    /**
     * @param  array<string>  $guards
     */
    protected function authenticate($request, array $guards): void
    {

        $guard = Filament::auth();

        if (!$guard->check()) {
            $this->unauthenticated($request, $guards);

            return;
        }

        $this->auth->shouldUse(Filament::getAuthGuard());

        /** @var Model $user */
        $user = $guard->user();

        $panel = Filament::getCurrentPanel();

        abort_if(
            $user instanceof FilamentUser ?
                (!$user->canAccessPanel($panel)) : (config('app.env') !== 'local'),
            403,
        );
    }

    protected function redirectTo($request): ?string
    {
        return Filament::getLoginUrl();
    }
}

class AuthenticateClient extends Middleware
{
    /**
     * @param  array<string>  $guards
     */
    protected function authenticate($request, array $guards): void
    {

        $guard = Filament::auth();

        if (!$guard->check()) {
            $this->unauthenticated($request, $guards);

            return;
        }

        $this->auth->shouldUse(Filament::getAuthGuard());

        /** @var Model $user */
        $user = $guard->user();

        $panel = Filament::getCurrentPanel();

        abort_if(
            $user instanceof FilamentUser ?
                (!$user->canAccessPanel($panel)) : (config('app.env') !== 'local'),
            403,
        );
    }

    protected function redirectTo($request): ?string
    {
        return Filament::getLoginUrl();
    }
}

I dunno...none of that looks problematic to me.

awcodes•4mo ago

Yea, I don’t see anything here that would affect the password.

Gaming

Programming

These credentials do not match our records.