Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Language setting not applied when signing in via SSO #16995

Open
salfers opened this issue Jul 26, 2024 · 13 comments · May be fixed by #17122
Open

Language setting not applied when signing in via SSO #16995

salfers opened this issue Jul 26, 2024 · 13 comments · May be fixed by #17122
Assignees
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@salfers
Copy link

salfers commented Jul 26, 2024

Deployment Type

Self-hosted

NetBox Version

v4.0.7

Python Version

3.11

Steps to Reproduce

  1. Set your user language to something that differs from the automatically detected language
  2. Clear cookies
  3. Log into Netbox via Google SSO

Bonus: if you log in via password everything works correctly.

Expected Behavior

4. Language from user settings is applied

Observed Behavior

4. The automatically detected language is used

You can see that the language cookie is not being created:
grafik

@salfers salfers added status: needs triage This issue is awaiting triage by a maintainer type: bug A confirmed report of unexpected behavior in the application labels Jul 26, 2024
@benhur1999
Copy link

I can confirm this behavior with external auth.

For reference, we have the following set in the netbox config:

REMOTE_AUTH_ENABLED = True
REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend'
REMOTE_AUTH_HEADER = 'HTTP_X_REMOTE_USER'

Environment: self-hosted, Netbox 4.0.7, Python 3.12

@m2martin
Copy link
Contributor

m2martin commented Aug 1, 2024

@salfers I checked it using AzureAD and cannot confirm/reproduce your behavior.

Was your user created by SSO or did it already exist?
Can you please also post your configuration parameters starting with REMOTE_AUTH_ (omit any sensitive data, of course)?

@benhur1999
Copy link

@m2martin In my case the user already existed.
It had it's language selection in trhe user prefereneces set to English, but Netbox showed German upon login, which is (browser language default.
Deleteing the language settings and setting it to English again and then applying the perferences using the save buttons sets English for the current session.

I'm using the following configuration parameter settings:

REMOTE_AUTH_ENABLED = True
REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend'
REMOTE_AUTH_HEADER = 'HTTP_X_REMOTE_USER'
REMOTE_AUTH_AUTO_CREATE_USER = True
REMOTE_AUTH_DEFAULT_GROUPS = ['staff']
REMOTE_AUTH_DEFAULT_PERMISSIONS = {}

@m2martin
Copy link
Contributor

m2martin commented Aug 2, 2024

With REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend' set, I can partially reproduce it. I can see the first page being loaded with the browser's language but any subsequent request will be displayed in the language from the user's properties.
Can you confirm this behavior?

@benhur1999
Copy link

@m2martin No, I cannot confirm the behavior. The language stays on the browser default and the user preferences have no impact.

What I did
1, open new Incognito-Tab in Chrome
2. open Netbox URL and authenticate using HTTP Auth
3. click on Devices ("Geräte")menu entry in the Devices ("Geräte") section
4. click on the Netbox logo menu

No change in language. I can only get it to switch to English (the users perference) by opening the user preferences and then Clicking "save"

@m2martin
Copy link
Contributor

m2martin commented Aug 2, 2024

I'm doing the same and can not confirm it. Can you please try it with v4.0.8? This is the most obvious difference between our tests.
(Maybe fixed with #16732)

@benhur1999
Copy link

@m2martin I'm running 4.0.8 since a few days. There was no change in behavior between 4.0.8 and 4.0.7.

@leo-pempera
Copy link

We are having the same issue.
Browser language is German, but netbox DEFAULT_LANGUAGE is set to en-us.
Upon login with SSO netbox is in german, not only the first site after login.
In the user settings the language is set to english. Upon saving them without changing anything the correct language is applied.
This resets every few days and the user has to change apply the user settings again.

@benhur1999
Copy link

FWIW, I also have set DEFAULT_LANGUAGE = 'en-us'

@m2martin
Copy link
Contributor

m2martin commented Aug 2, 2024

I think, I found it. Is LOGIN_PERSISTENCE = False?

@benhur1999
Copy link

@m2martin Yes, I have LOGIN_PERSISTENCE = False

Other settings:

LOGIN_REQUIRED = True
LOGIN_TIMEOUT = None

@m2martin
Copy link
Contributor

m2martin commented Aug 4, 2024

@arthanson I have a fix ready. You can assign it to me.

Root cause:
Language cookies will only be set on regular logins by the login view or renewed when having LOGIN_PERSISTENCE=True.
Setting the cookie in every workflow for every possible authentication method (local, OAuth, LDAP, etc.) is hard to maintain.
With the fix the language handling was moved to the CoreMiddleware to have it processed independent from the authentication method/backend.

@jeremystretch jeremystretch assigned m2martin and unassigned arthanson Aug 10, 2024
@jeremystretch jeremystretch added severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation and removed status: needs triage This issue is awaiting triage by a maintainer labels Aug 10, 2024
@jeremystretch
Copy link
Member

@m2martin I've assigned this to you, thanks.

@m2martin m2martin linked a pull request Aug 10, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants