Consider making LOGIN_REDIRECT_URL an env Value rather than hard-coded

[zachmullen]

No description provided.

[brianhelba]

What's the general use case for this?

I think many downstream projects will need to override this setting, to match their particular set of routes, but I don't see why most would need to set it differently per-deployment.

[zachmullen]

We commonly deploy SPAs backed by Girder 4 at different domains than the server. In those cases, a fully qualified login redirect URL is desired, and it will be deployment-specific.

[brianhelba]

I still don't understand how this is necessary. If an SPA logs in, they will do so as part of an OAuth2 flow, which will ultimately redirect them back to the "redirect URI" of the registered OAuth2 application, at the conclusion of their login process.

Is this a problem for cases where a user is provided a link directly to the Django app, outside of an OAuth2 flow? I can think of a few places where this happens:

• When confirming an email address, Django Allauth provides separate settings ACCOUNT_AUTHENTICATED_LOGIN_REDIRECTS, ACCOUNT_EMAIL_CONFIRMATION_ANONYMOUS_REDIRECT_URL, and ACCOUNT_EMAIL_CONFIRMATION_AUTHENTICATED_REDIRECT_URL. However, with the current configuration, this will ultimately redirect users to LOGIN_REDIRECT_URL after a successful email confirmation.

• When resetting a password, Django Allauth send users to a simple confirmation page. There is no high-level option to redirect them elsewhere.

• When logging out, Allauth sends users to ACCOUNT_LOGOUT_REDIRECT_URL (defaulting to /), though this can be dynamically overridden by passing a ?next= query string option in the logout URL.

I don't think that just changing LOGIN_REDIRECT_URL will get the end user back to the desired SPA page at the conclusion of all user account management actions.

I wonder whether a better practice is to encourage Django projects to mount a RedirectView at /, and then define their own setting to define the redirect target. I still don't think this will capture all of the aforementioned scenarios, particularly password reset. However, Allauth settings are tricky to understand (mostly because there's so many of them), so it might actually be more maintainable if downstreams generally ignore Allauth settings and are responsible for a custom locally-defined SPA URL setting instead.

[zachmullen]

Sorry, it's been a while on this so I may have forgotten some context, but I think the main issue here is during new user registration, especially when email verification is optional or disabled. In those cases, the user completes registration, and they get taken to a page that actually gives a 500 error because the corresponding template doesn't exist out of the box.