16995 Move language handling to Middleware

[m2martin]

Fixes: #16995

Decouples language activation from login form to have it handled by CoreMiddleware which will also trigger language activation on any type of login (e.g. SSO).

[jeremystretch]

Are we sure this is needed? IIRC the first authenticated response should always be a redirect, so I'd expect the language cookie should already be set.

[m2martin]

Your assumption is true when the login form or even some types of SSO is used, but not for netbox.authentication.RemoteUserBackend.

If you're using header-based authentication without that code fragment, you'll end up with the first page being displayed in the browser's default language, despite having a correct cookie.

[jeremystretch]

Ah, right.

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further action is taken.

[bctiemann]

@m2martin Could you please rebase this PR? I tried to resolve what seemed like a trivial merge conflict and found that there are a large number of tests failing due to references to settings.AUTH_EXEMPT_PATHS which does not exist, as well as missing imports (i.e. parse).

[jeremystretch]

I've rebased this against develop, but it's still not clear to me what the recommended convention is for setting and renewing the language cookie.

[m2martin]

What exactly are you missing? Do you mean the "Django recommended way"?

[jeremystretch]

Do you mean the "Django recommended way"?

Yeah. It's not clear to me what Django's recommended practice is for directly managing the language cookie. It feels like we're reinventing the wheel a bit.

It also has me wondering if we should even be using a separate cookie for the language, as opposed to session data. IIRC Django uses a separate cookie to remove the session middleware as a dependency, but obviously that doesn't apply here.

[m2martin]

Hmm, I understand your concerns but I think I can't provide any satisfying answer...

AFAIK, Django has had language and sessions coupled in the past but now tries to de-couple them (remove language from sessions and fully rely on the cookie as detection mechanism).

I've found no other way to implement all possible login cases.
There are two code points where we can kick in - before and after get_response(). Because of this, there are two code blocks. On the latter, we can't change the language anymore because it has already been set and activated by other instances.
On the first, we can follow the Django-recommended way of using translation.activate().

It could be simplified if it is acceptable to have the first page-load being displayed in the wrong language.

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further action is taken.