Weird authentication behaviour

[goyne]

Package

Panel builder

Package Version

v3.2.43 + L10.46

How can we help you?

Hi,

I'm facing some weird authentication behaviour I do not understand. Not sure if it's a bug.

My User model implements the FilamentUser and MustVerifyEmail contracts. After registering a new user, I expect to be redirected to the /email-verification/prompt page if the e-mail address has not yet been verified. That doesn't happen. Instead, the error message is shown 'These credentials do not match our records.'

If I don't implement FilamentUser on my User model, everything works as expected. In the panel configuration, I included ->emailVerification().

Any thoughts? Am I missing something?

[leandrocfe]

Could you share the project on the github? I can take a look

[goyne]

Thanks, but fixed it already.

[goyne]

Fixed.
Because of the FilamentUser contract on the User model, I had to implement the method canAccessPanel. I had copied that from the documentation:
public function canAccessPanel (Panel $panel) : bool { return $this->hasVerifiedEmail(); }

That method throws a 403 instead of redirecting to the verify prompt.

[hyphen81]

I'm having this same issue on my production environment on an app I rolled out last week. I have 3 panels, 2 of which are internal only, and one is client facing. All my internal folks can login just fine, but clients can't. I have the MustVerifyEmail trait and I'm implementing the FilamentUser contract. This is my canAccessPanel method:

    public function canAccessPanel(Panel $panel): bool
    {
        if ($panel->getId() == 'client') {
            return $this->hasVerifiedEmail();
        } else if ($panel->getId() == 'admin') {
            return $this->role->is_internal && $this->hasVerifiedEmail() && $this->hasAdminRole();
        } else if ($panel->getId() == 'app') {
            return $this->role->is_internal && $this->hasVerifiedEmail();
        } else {
            return true;
        }
    }

Did anyone figure this out? What makes this more confusing is that I can't reproduce it locally, but it's happening in production. Totally lost on what might be the root cause.