django-allauth: Tokens do not get stored when using settings-based provider credentials

Work-around: Define a custom SocialAccountAdapter in settings SOCIALACCOUNT_ADAPTER = "my_project.my_socialaccount_adapter.MySocialAccountAdapter"

from allauth.socialaccount.adapter import DefaultSocialAccountAdapter


class MySocialAccountAdapter(DefaultSocialAccountAdapter):
    """
    Temporary work-around for: https://github.com/pennersr/django-allauth/issues/2467
    """

    def get_app(self, request, provider):
        # NOTE: Avoid loading models at top due to registry boot...
        from allauth.socialaccount.models import SocialApp

        # 1 added line here
        from allauth.socialaccount import app_settings

        config = app_settings.PROVIDERS.get(provider, {}).get('APP')
        if config:
            app = SocialApp(provider=provider)
            for field in ['client_id', 'secret', 'key']:
                setattr(app, field, config.get(field))

            # 3 added lines here
            app.key = app.key or "unset"
            app.name = app.name or provider
            app.save()

        else:
            app = SocialApp.objects.get_current(provider, request)
        return app

I faced similar issue when I enabled social signup page which is what I wanted. Looking at the error message ( if condition) I got a clue and tried to turn off Social Token as follows in settings.py SOCIALACCOUNT_STORE_TOKENS = False

Things work as developer expected it to work without coding for custom Social Account Adapter.

Here’s my workaround, taking from the others who have posted here:

class CustomSocialAccountAdapter(DefaultSocialAccountAdapter):
    def get_app(self, request, provider):
        # NOTE: Avoid loading models at top due to registry boot...
        from allauth.socialaccount.models import SocialApp

        # 1 added line here
        from allauth.socialaccount import app_settings

        config = app_settings.PROVIDERS.get(provider, {}).get('APP')
        app = SocialApp.objects.get_or_create(provider=provider)[0]
        app.client_id = config['client_id']
        app.secret = config['secret']
        app.key = config.get('key', '')
        return app

i didn’t see the point of saving the secrets in raw to the db.

This was fixed via 639b4668

So the current workaround is to not use settings based credentials and to make sure that when creating the social application instance in the admin, to ensure the correct site is included in the list.

also, overriding scope is ok in the settings, you just can’t use the “APP” key

    "vimeo_oauth2": {
        "SCOPE": ["public"],
    },

I had this issue on a newly setup Django project and I was able to figure out the root of this issue in my case. Looking at the socialapp_sites table which has the app_id and site_id I noticed the site_id was set to 3 (I set my settings.py SITE_ID = 2). I only have two sites, the example.com and the 127.0.0.1 which i created in admin panel. After looking at django_site table it showed that #2 was assigned to example.com so when I created the local host site it was given #3. How did this happen? I copied the settings from the first attempt of my project and the site_id was set to 2. I migrated that and then went ahead and created the 127.0.0.1 site. (In my first attempt I had site_id = 1 before migrating). So simply changing the SITE_ID to 3 in settings.py and making sure that SOCIALACCOUNT_STORE_TOKENS was set to True solved this for me.

Thanks @benjaoming for the workaround! As of November 16, 2022 the issue (and the workaround) still exist for me:

django==4.0
djangorestframework==3.14.0
django-allauth==0.51.0

SocialToken’s require a matching SocialApp to link to via a ForeignKey there is nothing conditional about the SocialApp object existing, it must exist. What this workaround is doing is creating the SocialApp with dummy data so that the client id and secret are still loaded from the SOCIALACCOUNT_PROVIDERS[...]['APP'] .

I think the proposed workaround needs some rethinking because it’ll be creating a new SocialApp entry every time get_app is called. It needs to check for an existing entry.