Incompatible with social-auth-app-django 6+

[pwnage101]

TL;DR:

Users can no longer log in to IDAs (via JWT) that pair this library with social-auth-app-django 6.0+ / social-auth-core 5.0+: the login attempt fails fatally before reaching the identity provider.

Context

JwtRedirectToLoginIfUnauthenticatedMiddleware redirects unauthenticated users (HTTP 302) to the login URL (e.g. /login), which in turn redirects to the social-auth begin view /login/edx-oauth2/. The browser reaches that view with a GET.

In social-auth-app-django 6.0.0 (2026-06-23) / social-auth-core 5.x, the begin view now always requires POST, so that GET is rejected:

Method Not Allowed (GET): /login/edx-oauth2/

POST was opt-in via SOCIAL_AUTH_REQUIRE_POST in 5.4.0 (default off, so GET still worked); 6.0.0 made it mandatory and removed the setting.

The middleware's only override hook, get_login_url(), changes the target URL but not the HTTP method, so there is no configuration-based workaround.

Possible fix (high-level)

(Besides the workaround of just downgrading social-auth-app-django)

Make login initiation use POST instead of a 302→GET redirect, e.g.:

1. have process_response return an auto-submitting POST form (carrying next), or
2. redirect to a GET-accepting shim view that POSTs to the begin endpoint.

Either way, the fix seemingly lies within this edx-drf-extensions repo.

[kdmccormick]

@robrap, your Slack message implied that we can work around this for now by adding a common constraint for social-auth-app-django<6 and social-auth-core<5, is that right?

[robrap]

@kdmccormick: I did imply that we add those constraints, and that was purely based on how we've handled this in the past. @pwnage101 seemed to think this would be a good short-term solution. I have no reason to believe it won't work, but we'll see if anything else comes up if we try. I also don't know enough to know if both constraints are needed, or if one would constrain the other.

[pwnage101]

I believe it works because it's exactly how we fixed it for all 4 IDAs for enterprise:

• chore: downgrade social-auth-* packages to fix JWT auth failures edx/enterprise-subsidy#56
• chore: pin social-auth-* packages that have working JWT auth edx/license-manager#66
• chore: downgrade social-auth-* packages to fix JWT auth failures edx/enterprise-catalog#139
• chore: downgrade social-auth-* packages to fix JWT auth failures edx/enterprise-access#221

And they've all been deployed to prod. In every case, JWT auth wasn't working before (HTTP 405 on /login/edx-oauth2), and now it is.

Here's a generic pin that I'd propose for the broader common constraint file:

# pinning social-auth-* packages to the latest version compatible with
# edx-drf-extensions<=10.6.0.  Consider removing these pins when this issue is resolved:
# https://github.com/openedx/edx-drf-extensions/issues/561
social-auth-app-django>=5.9.0,<6.0.0
social-auth-core>=4.9.1,<5.0.0

[timmc-edx]

What if we added those constraints to edx-drf-extensions directly? I believe that would propagate to any IDAs using the library. Then we wouldn't have to upgrade everything in lockstep once we have a fix.

[timmc-edx]

(Tracking within 2U as BOMS-672.)

[timmc-edx]

...oh, we can't constrain in here because it's not a dependency of this package. That makes sense. :-)

[timmc-edx]

Additional info:

• Re-allow to opt-in GET request in begin flow python-social-auth/social-app-django#1020 -- we may not even want the new GET-only behavior, since it breaks SSO flows from "SSO portal" type sites (e.g. Okta, OneLogin, MyApps)
• I'm fairly sure that the redirect is coming from the login_required -- and that Django code doesn't appear to have changed meaningfully from 4.x to 5.x. So I don't think this is a Django/social-auth version mismatch. It's more likely to be an incompatibility with us using redirects at all.