pennersr/django-allauth

Email verification when a different user is already logged in - headless

Closed this issue · 5 comments

The original issue #615 was closed via ce1658c which does not seem to be used in headless.

when a user is already logged in and some other user user on the same browser verifies his email address (by clicking the verification link in his email).

it creates problem when
ACCOUNT_LOGIN_ON_EMAIL_CONFIRMATION = True

it does not Sign out the logged in user ( the logged in user is not changed )

is this the expected behavior.

In my case ACCOUNT_LOGIN_ON_EMAIL_CONFIRMATION is false and the original user is still not being logged out. When I post to api/_allauth/browser/v1/auth/verify it returns 200 instead of 401. request.user is user B (the one verifying their email), but is_authenticated is true although they haven't logged in at all.

I can confirm that the currently logged in user is not automatically logged out when the verifying user is verifying the email address. That needs to be addressed indeed. However, it is not the case that the verifying user is somehow signed in. A 200 is indeed returned, but that is still pointing to the already logged in user.

I didn't check it again when writing this, but as far as I remember from my original debugging is_authenticated is based on request.user which is still the originally logged-in user.
So the response data indicates a current session - although this should be referring to the verifying user it's actually still coming from the currently logged-in user.

is anyone working in this currently if not then can I be assigned for this?

I am not sure we need to make this symmetrical to the headed behavior. Points:

  • While allauth can logout the currently signed in user, retracting any access tokens that were handed out is an issue.
  • When the frontend GETs the information on the verification email, it has all the information it needs. It knows what user is logged in, it can detect that this is for some other user, so it can decide to logout (and drop its access tokens as well). So, is there really a need to hardcode this behavior?

The above is concerning logging out existing users. As for logging in on confirmation, that does need to work, but, only if there is no other user signed in because of above mentioned reasons.

I've added a test case (d30b641) just to be sure, but it is already working properly. As mentioned, the frontend has all the information it needs, so from an API point of view what we currently have is most flexible.