Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Locale not correct on social login #171

Open
giorgio93p opened this issue Jan 17, 2020 · 3 comments
Open

Locale not correct on social login #171

giorgio93p opened this issue Jan 17, 2020 · 3 comments

Comments

@giorgio93p
Copy link
Collaborator

In fact, this issue has two different cases

  1. Account creation on social login: locale id is not set correctly, it's always the default one. We can easily fix this by overriding allauth's social account adapter (see commit a306b1d).
  2. Social login with existing account: locale cookie is never written (because execution does not pass from our login view for normal logins), so the locale shown after login is the one that it was before login, instead of the one saved in user profile. Since we need a response on which to set the cookie and since each social provider has different urls and views, this can't be fixed equally easily.
@adamhooper
Copy link
Contributor

Urgh. It looks like we'll need the allauth.account.signals.user_logged_in

in allauth.account.utils.perform_login():

    try:
        adapter.login(request, user)
        response = HttpResponseRedirect(
            get_login_redirect_url(request, redirect_url))

        if signal_kwargs is None:
            signal_kwargs = {}
        signals.user_logged_in.send(sender=user.__class__,
                                    request=request,
                                    response=response,
                                    user=user,
                                    **signal_kwargs)
        adapter.add_message(
            request,
            messages.SUCCESS,
            'account/messages/logged_in.txt',
            {'user': user})
    except ImmediateHttpResponse as e:
        response = e.response
    return response

The adapter can't add a cookie to the response. (Except in add_message(), but that's waaaaay too janky.)

So we're forced to modify the response's cookies in a signal handler. Frustrating! But that seems to be our only recourse.

@giorgio93p
Copy link
Collaborator Author

We could also override the urls and views of the specific providers we want to be able to use. Not general, but avoids signals.

@adamhooper
Copy link
Contributor

That's too much work. Signals are the least-janky way.

giorgio93p added a commit that referenced this issue Jan 20, 2020
Effectively undoes commit 0f8018e

The approach of signals is required because of social login. See issue
#171
for details as to why.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants