Social login does not show Terms of Use

[jochenklar]

An initial registration by passes the terms of use text an dcheckbox. Maybe SOCIALACCOUNT_AUTO_SIGNUP = False can help.

[jmfrenzel]

Can reproduce this. In case of SOCIALACCOUNT_AUTO_SIGNUP = True and using an ORCID account which has set visibility of its Email address to everyone (public to all).
However allauth will present the confirmation and thus the TOU confirmation in cases it can't access the email address of the ORCID account due to user set visibility restrictions.

Our setup for testing TOU popup + confirmation running with ORCID as the sole auth method shown to the users.
local.py

ACCOUNT_TERMS_OF_USE = True 
ACCOUNT = True
SOCIALACCOUNT = True
SOCIALACCOUNT_SIGNUP = True
SOCIALACCOUNT_AUTO_SIGNUP = True 

[jochenklar]

Hi @jmfrenzel , so if people have a public email, the TOU is skipped, right? Is that a problem, or can e close here?

[jmfrenzel]

That is right. It is a problem since our use must agree to the TOU.
Solution would be

1. check if SOCIALACCOUNT_AUTO_SIGNUP = 'True'
   and
   ACCOUNT_TERMS_OF_USE = 'True'
2. If both are 'True' force SOCIALACCOUNT_AUTO_SIGNUP = 'False'

[MyPyDavid]

I need to implement this for our instance as well. So far Ive set SOCIALACCOUNT_AUTO_SIGNUP=True , think I also need to check for current users to agree to the TOU at login.
Was there something implemented from this issue?

[jochenklar]

Try it with SOCIALACCOUNT_AUTO_SIGNUP=False? Then it should show the signup form nevertheless. (I hope.)

[MyPyDavid]

The auto signup can be interrupted in the adapter, like so for example(?):

    def is_auto_signup_allowed(self, request, sociallogin):
        # If email is specified, check for duplicate and if so, no auto signup.
        auto_signup = app_settings.AUTO_SIGNUP
        if settings.ACCOUNT_TERMS_OF_USE:
            # if sociallogin.user.id is None:
                return False
            # return ConsentFieldValue.objects.filter(user__id=sociallogin.user.id).exists()
        return auto_signup

• https://github.com/pennersr/django-allauth/blob/0f19d2087fb5339e7db2ee2b7f7b6d9e7788ceef/allauth/socialaccount/adapter.py#L156

[MyPyDavid]

I've found a way for showing the ToU at signup and for existing users (after login, which would require some changes to the rdmo home view).

The auto signup can be interrupted, then the SocialSignupForm can be adapted to (similar to the SignupForm in rdmo.accounts.adapter). This SocialSignupForm can be used via the setting SOCIALACCOUNT_FORMS .

    def is_auto_signup_allowed(self, request, sociallogin):
        # If email is specified, check for duplicate and if so, no auto signup.
        auto_signup = app_settings.AUTO_SIGNUP
        if settings.ACCOUNT_TERMS_OF_USE:
                return False
        return auto_signup

    if ACCOUNT_TERMS_OF_USE:
        SOCIALACCOUNT_FORMS = {"signup": "accounts.forms.SocialSignupForm"} # path in rdmo-app

For existing users, the use case might be that, when the text of the ToU changes, that users need to re-confirm their consent.
This would require an update consent page (view, form and url) and a check at login if the ToU is enable and if the user has the ConsentFieldValue. I've hacked this now into the rdmo-app but think it could better be in source as well, maybe already via a viewset.

[jochenklar]

Yes, nice, but you could just set AUTO_SIGNUP to false right?

I discussed with @m6121 something similar to the "update" use case above: LDAP. I think we need to have a signal handler which checks if a user has consented yet and does not let them log in before clicking on a to-be-added update consent page.

In https://github.com/django-daiquiri/daiquiri I used something similar (but only with allauth)
https://github.com/django-daiquiri/daiquiri/blob/master/daiquiri/auth/adapter.py#L28. account_pending is just a static landing page in this case.

Maybe this needs to be done with a custom Middleware. We could also disable users on login which have not consented yet, but this might cause trouble with other reasons to disable a user.

[MyPyDavid]

Yeah, it works with just SOCIALACCOUNT_AUTO_SIGNUP=False and without overwriting the auto_signup_allowed method as well.

[MyPyDavid]

Would it be an idea to use this package https://github.com/cyface/django-termsandconditions or would it be too much?
It would need to be adapted for REST/React anyways I guess.

I'm not sure if only signal handler of user_logged_in with django-allauth would be sufficient, I have no experience with the handling of deactivated users .

Think so too that it needs a custom Middleware (maybe with some excluded paths like in termsandconditions/middleware.py) .

The current ConsentFieldValue model would need another field like date_accepted to support an update functionality.

[jochenklar]

I would say its to much and maybe conflicts with the model field we already have.

I need to think about this, maybe a middleware just needs to check if request.user.consent is there and otherwise deactivate the user. This would mean one database query on each request, which is not super ... Maybe we can somehow store that in the session.

[jochenklar]

Basically this line: https://github.com/cyface/django-termsandconditions/blob/main/termsandconditions/middleware.py#L37 but with some performance tweaking: set a flag in the session the first time and then check this flag first.

In RDMO every path would be protected.