fix(login): render login page when the Site row for SITE_ID is missing

[Maffooch]

Problem

GET /login returns an HTTP 500 on instances where the django_site row referenced by SITE_ID is absent from the database:

django.contrib.sites.models.Site.DoesNotExist: Site matching query does not exist.
  ...
  File ".../django/contrib/auth/views.py", line 113, in get_context_data
    current_site = get_current_site(self.request)
  File ".../django/contrib/sites/shortcuts.py", line 16, in get_current_site
    return Site.objects.get_current(request)
  File ".../django/contrib/sites/models.py", line 59, in get_current
    return self._get_site_by_id(site_id)

Django's LoginView.get_context_data() unconditionally resolves the current Site while building the login page context. Site.objects.get_current() looks the row up by SITE_ID and raises Site.DoesNotExist when that row is missing. Because this happens on the anonymous login page itself, the failure locks users out entirely — they cannot even reach the sign-in form.

Root cause

DojoLoginView (dojo/user/ui/views.py) inherits Django's LoginView.get_context_data, which hard-depends on a Site row existing for SITE_ID. The Site object is only used to populate site/site_name in the template context, so a missing row should never take the whole page down.

Fix

Override get_context_data on DojoLoginView to resolve the current site defensively, falling back to RequestSite(request) when Site.DoesNotExist is raised. This mirrors what Django itself does in get_current_site() when the sites framework is not installed, so the login page always renders. No schema change.

Why no migration

Seeding the Site row via a data migration was considered and rejected:

• It would not help an instance whose row is later removed, or whose SITE_ID points at a different (missing) row — the page would 500 again.
• This is a code-robustness gap, not a schema gap: the login page must never 500 because an optional context row is missing.
• Migrations are one-way and heavier than a small defensive fallback that fixes every variant of the condition.

The defensive fallback resolves all cases with zero migrations.

Tests

New unittests/test_login_view_missing_site.py:

• Control: Site row present → GET /login returns 200.
• Regression: all Site rows deleted → GET /login returns 200 (previously 500 with Site.DoesNotExist).

Verified locally: the regression test reproduces the exact Site.DoesNotExist traceback against the current code and passes with the fix; the control case and the existing login-touching test (test_permission_policy_headers) stay green.

Downstream (commercial plugin) impact

The commercial plugin overrides the /login route with a ProLoginView that subclasses DojoLoginView and does not override get_context_data, so it inherits this fix directly. Its login template does not reference site/site_name, so no template change is required there. This change therefore resolves the reported errors on those instances without any additional downstream code.

---

Generated by Claude Code