The difference in behavior was using social login buttons for an existing account vs. creating a new account. This is another damn django-allauth regression, starting in 0.57.0. It seem to be this commit that is to blame: https://github.com/pennersr/django-allauth/commit/be779dfee5a328a3a42edc2c95... In allauth/socialaccount/models.py:lookup(self):285 there is an attempt to look up the social account as one that already exists. If that fails, this commit calls self.account.get_provider() without passing the request object, which leads to the eventual error. I believe this is a django-allauth bug, and have submitted a pull request to fix it here: https://github.com/pennersr/django-allauth/pull/3548 Patch also included below. --Jered --- a/allauth/socialaccount/helpers.py +++ b/allauth/socialaccount/helpers.py @@ -205,7 +205,7 @@ def _add_social_account(request, sociallogin): def complete_social_login(request, sociallogin): assert not sociallogin.is_existing - sociallogin.lookup() + sociallogin.lookup(request) try: get_adapter().pre_social_login(request, sociallogin) signals.pre_social_login.send( --- a/allauth/socialaccount/models.py +++ b/allauth/socialaccount/models.py @@ -274,12 +274,12 @@ class SocialLogin(object): return False return get_user_model().objects.filter(pk=self.user.pk).exists() - def lookup(self): + def lookup(self, request=None): """Look up the existing local user account to which this social login points, if any. """ if not self._lookup_by_socialaccount(): - provider_id = self.account.get_provider().id + provider_id = self.account.get_provider(request).id if app_settings.EMAIL_AUTHENTICATION or app_settings.PROVIDERS.get( provider_id, {} ).get("EMAIL_AUTHENTICATION", False): ----- On Dec 6, 2023, at 3:21 PM, Mark Sapiro mark@msapiro.net wrote:
On 12/6/23 11:00, Jered Floyd wrote:
These errors are generated to me as the admin, and in the elided environment section SITE_ID is indeed 0, but I'm at a loss to imagine why this happens only sometimes!
For me, on a test installation with SITE_ID = 0, this only occurs at https://example.com/accounts/social/connections/
Other URLs such as https://example.com/accounts/password/change/ and https://example.com/accounts/email/ do not throw this exception.
Here's the code: ``` def get_current(self, request=None): """ Return the current Site based on the SITE_ID in the project's settings. If SITE_ID isn't defined, return the site with domain matching request.get_host(). The ``Site`` object is cached the first time it's retrieved from the database. """ from django.conf import settings
if getattr(settings, "SITE_ID", ""): site_id = settings.SITE_ID return self._get_site_by_id(site_id) elif request: return self._get_site_by_request(request)
raise ImproperlyConfigured( 'You\'re using the Django "sites framework" without having ' "set the SITE_ID setting. Create a site in your database and " "set the SITE_ID setting or pass a request to " "Site.objects.get_current() to fix this error." ) ```
I tried patching it from ``` if getattr(settings, "SITE_ID", ""): ``` to ``` if getattr(settings, "SITE_ID", None) is not None: ``` but that's even worse. It throws a bunch of "django.contrib.sites.models.Site.DoesNotExist: Site matching query does not exist." errors.
Somehow, get_current is being called without a request object in the cases where it fails.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
_______________________________________________ Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to jered@convivian.com