Chrome OS SAML SSO webview does not respect managed Sign-in Language
Reported by
samuel.k...@airbnb.com,
Jun 27 2018
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3472.3 Safari/537.36 Platform: Chrome OS Steps to reproduce the problem: 1. Have a Chrome OS device with a device language set. 2. Use Chrome device policy to set Sign In Language to something else. 3. Sign in to the device with a SAML SSO user 4. The screens shown in the webview will be in the device language, not the sign in language. What is the expected behavior? SSO webview uses the managed sign in language and not the device language. What went wrong? We've got a large number of guado devices which default out of the box to Dutch, but are actually being used in Germany. At device setup and enrollment time, most devices were set to English for their device language, and therefore the webview is also in English. That's fine for this site. The issue is that for devices where the device language wasn't changed from the default, the webview is shown in Dutch, which the users don't speak. Everything else they see is in the configured sign in language, so we expect this to be the same, especially since it's part of the same sign in flow they see. Did this work before? N/A Chrome version: 69.0.3472.3 Channel: stable OS Version: 10575.58.0 67.0.3396.99 Flash Version:
,
Jun 27 2018
- the device defaults to Dutch Yes - the DeviceLoginScreenLocales policy is set to "de-DE" (according to chrome://policy) Yes, or en-US - the sign-in screen UI is in German Yes, or English if set to en-US - the "Sign in to your Chromebook" screen is in... Dutch or German? German, or English if set to en-US - the SAML SSO Page is in... Dutch or German? Dutch (this is the only part which seems to be off) - After sign-in, the pages informing about Chrome Sync etc. are... Dutch or German? German, or whatever language the user has configured
,
Jul 5
Thanks, this is very helpful. I suspect that kAcceptLanguages does not reflect the policy value. It seems that on the sign-in screen, it gets set to its default on registration [1], the default being a predefined Accept-Language list for the current locale. But this may be too early, the locale set by DeviceLoginScreenLocales is probably not applied yet. I'd suggest that we set kAcceptLanguages to |l10n_util::GetStringUTF8(IDS_ACCEPT_LANGUAGES)| explicitly after the policy-set locale has been applied ([2] for webui, unsure where for the new UI) or explicitly clear it if there's no policy-set locale. [1] https://cs.chromium.org/chromium/src/chrome/browser/ui/prefs/prefs_tab_helper.cc?rcl=c1bd75f2cab8d8d689f9effacbf88e4a2866f667&l=502 [2] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/ui/login_display_host_webui.cc?rcl=dc7f5252145dbef0c1663176a90e86285d5e0e3b&l=252 |
||
►
Sign in to add a comment |
||
Comment 1 by pmarko@chromium.org
, Jun 27 2018