fix(socialaccount): Allow account connections page to establish SITE_ID from request

[jeredfloyd]

Similar to the fix in #3548 , the subprovider refactoring in 0.55 created the necessity to identity SITE_ID based on the request in get_provider_account, which is used in the Django template for the Account Connections page.

[coveralls]

coverage: 95.785%. remained the same
when pulling d55eb5e on jeredfloyd:fix-site-id-connections-2
into 1f8c59d on pennersr:main.

[pennersr]

Hmm, here we are accessing a model stored in the database. And, we should be able to do so even beyond the context of a request. So, when looking up the actual provider/app further down the line, it is actually wrong to try and limit the available apps by those active on the site.

Can you try if this solves your issue instead?:

diff --git a/allauth/socialaccount/adapter.py b/allauth/socialaccount/adapter.py
index 902c5782..a56ba482 100644
--- a/allauth/socialaccount/adapter.py
+++ b/allauth/socialaccount/adapter.py
@@ -228,7 +228,10 @@ class DefaultSocialAccountAdapter(object):
         provider_to_apps = {}
 
         # First, populate it with the DB backed apps.
-        db_apps = SocialApp.objects.on_site(request)
+        if request:
+            db_apps = SocialApp.objects.on_site(request)
+        else:
+            db_apps = SocialApp.objects.all()
         if provider:
             db_apps = db_apps.filter(Q(provider=provider) | Q(provider_id=provider))
         if client_id:

... and, if so, does this address the previous issue as well?

[jeredfloyd]

Yes! Your proposed change resolves both issues.

[pennersr]

Ok, thanks for confirming. Will apply this and revert the other change.

[pennersr]

✅

[pennersr]

Closed via e5c480c