Adding openid_connect to INSTALLED_APPS causes login view to fail

[enzedonline]

When I add 'allauth.socialaccount.providers.openid_connect' to INSTALLED_APPS, the login page fails to load with a SocialApp.DoesNotExist error in allauth/socialaccount/adapter.py line 288, DefaultSocialAccountAdapter.get_app() method.

This happens whether or not an OIDC provider has been defined.

Trapping the error, it seems to be looking for a social app with provider 'accounts'.

This will occur with

SOCIALACCOUNT_PROVIDERS = {
    "google": {
        "SCOPE": ["profile", "email"], 
        "AUTH_PARAMS": {"access_type": "online"}
    }, 
    "facebook": {
        "METHOD": "oauth2", 
        "SCOPE": ["email", "public_profile"], 
        "VERIFIED_EMAIL": True
    }, 
}

or

SOCIALACCOUNT_PROVIDERS = {
    "google": {
        "SCOPE": ["profile", "email"], 
        "AUTH_PARAMS": {"access_type": "online"}
    }, 
    "facebook": {
        "METHOD": "oauth2", 
        "SCOPE": ["email", "public_profile"], 
        "VERIFIED_EMAIL": True
    }, 
    "openid_connect": {
        "APPS": [
            {
                "provider_id": "oidc_linkedin", 
                "name": "LinkedIn", 
                "client_id": "xxxx", 
                "secret": "xxxx", 
                "settings": {"server_url": "https://www.linkedin.com/oauth/.well-known/openid-configuration"}
            }
        ]
    }
}

With the latter, I can call self.list_apps(request, provider='oidc_linkedin', client_id=client_id) and successfully and successfully return the LinkedIn app. Loading the page doesn't get that far however.

Removing 'allauth.socialaccount.providers.openid_connect' loads the page fine. I can see the Facebook and Google apps load.

This does not affect the social connect pages, only login page. I've tried with own custom template and with allauth template. Same result, it seems to trigger before the template loads.

Not sure if this is a bug, or some config that missing that I've not picked up inthe docs.

[pennersr]

There is no reason why allauth would go looking for a provider called accounts without that being configured somehow, unless the project's URL routing somehow mistakenly interprets the accounts in your /en/accounts/login as a provider ID. I would recommend you first use standard URL routing (e.g. don't auto prefix /en/) and then figure out why things start breaking when you gradually expand from there...

[pennersr]

Closing -- feel free to reopen if you have a reproducible scenario with an uncustomized allauth.

[enzedonline]

It's redirected to /en as it's a multilingual site. No site exists at /.
'accounts' isn't configured anywhere other than being a prefix for the allauth urls.
It's only on the login view, and only when OIDC is added to INSTALLED_APPS that this issue arises with or without an OIDC provider defined.

Your suggestion regarding the urls did lead me to find a duplicate path for allauth.urls though:

urlpatterns = urlpatterns + i18n_patterns(
    ...
    re_path(r'^accounts/', include('allauth.urls')),
    ...
    re_path(r'', include('allauth.urls')),
    ...
)

When I take out the second, the error goes away. It was there for some historic reason I can only guess.

I couldn't track what calls with provider='accounts' in the end. From searching and stepping through the code, it comes from the get_providers & provider_login_url templatetags, but these don't even get called when the error gets thrown. I can even see the error in the console when starting the server.

Anyway, thanks for the help, much appreciated!