[keycloak-dev] Locale cookie vs ui_locales priority

Wed Aug 22 07:59:02 EDT 2018

On 8/22/2018 3:47 AM, Marek Posolda wrote:
> +1 for the LocaleSelectorSPI. Now I recall that on the previous project
> I was working few years ago (GateIn Portal) we had such flexibility due
> the people having different requirements on how the locale should be
> chosen :)
>
> Regarding your proposal, It looks like a good start. But maybe I would
> rather remove the class LocaleHelper entirely and extract the stuff
> directly to the DefaultLocaleSelectorProvider? This will have an
> advantage that DefaultLocaleSelectorProvider may have various protected
> methods (EG. like getLocaleFromCookie, getLocaleFromUiLocalesParameter,
> getLocaleFromUserProfile etc), so that if someone wants to override
> default behaviour, he doesn't need to extract whole code, but just
> extend from DefaultLocaleSelectorProvider and call protected methods
> directly etc?
>
> Also I wonder if DefaultLocaleSelectorProvider should have some
> configuration option, which will allow to easily specify default order
> (EG. "cookie kclocale_param profile ui_locale_param accept_header realm"
> ) so that 90% of people can just configure the value in standalone.xml
> without a need to implement their own LocaleSelectorProvider?
-1 to configuration via standalone.xml.  In general, I don't think we 
should create a simplified interface to address an edge case. That just 
introduces ongoing maintenance.  What we have now gets it right 99.9% of 
the time.

+1 to LocaleSelectorSPI.  Even if we did the standalone.xml thing, 
somebody would still need LocaleSelectorSPI for complex cases.
>
> Marek
>
> On 15/08/18 18:13, Johannes Knutsen wrote:
>> I did some quick work on extracting an LocaleSelectorSPI. Please have
>> a look at https://github.com/keycloak/keycloak/compare/master...knutz3n:feature/locale-spi.
>> Thoughts?
>>
>> - Johannes
>>
>> On Tue, Aug 14, 2018 at 8:32 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
>>> The most common case is that the same user uses the browser. So if the user
>>> has actively changed the locale in Keycloak it should stay like that. I
>>> would actually suggest that if the user has changed the locale in Keycloak,
>>> you should have the locale added to the token so the application can update
>>> it's locale. That would result in all applications in the realm using the
>>> same locale for the user.
>>>
>>> Now if we change it to what you are suggesting you can end up with
>>> situations where the first login page is displayed in one language, then
>>> once the user has entered username/email it would end up switching to the
>>> locale associated with the user.
>>>
>>> If you really don't like that behaviour I would suggest we either introduce
>>> a LocaleSelectorSPI where you can change the logic with a custom provider.
>>> Alternatively, we could potentially add an option on the realm to be able to
>>> disable the locale selector on Keycloak, which means that the user wouldn't
>>> be able to change the locale and ui_locales would always take precedence. In
>>> either case I think it's best to keep the current behaviour as the default,
>>> with some way of being able to change it.
>>>
>>> On Tue, 14 Aug 2018 at 12:56, Johannes Knutsen <johannes at kodet.no> wrote:
>>>> It currently works the way you describe it. The ui_locales parameter
>>>> is taking effect as long as the locale cookie isn't set. However, the
>>>> logic implies that you always expect the same user to authenticate and
>>>> our preference is that the user should get a login page matching the
>>>> locale of the client which sends the user to the login page, if the
>>>> client specified preferred locales as an ui_locales parameter.
>>>> Using the locale cookie to override the ui_locales parameter makes the
>>>> user experience inconsistent when moving from a client with a locale
>>>> different from the last logged in user's preferred locale.
>>>>
>>>> A proposed change is to change locale priority as follows:
>>>> 1. kc_locale query parameter. This updates the user's locale and locale
>>>> cookie.
>>>> 2. user profile locale if a user is authenticated. This updates the
>>>> locale cookie.
>>>> 3. ui_locales query parameter. If ui_locales contains the locale
>>>> cookie value, return it. Otherwise, return the first locale available
>>>> from ui_locales
>>>> 4. locale cookie
>>>> 5. accept language http header
>>>>
>>>> Is this change something you would consider merging if I create a pull
>>>> request? Any other adjustments or thoughts regarding such a change?
>>>>
>>>> - Johannes
>>>>
>>>> On Tue, Aug 14, 2018 at 9:16 AM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>> The way at least it was supposed to work was that the Locale cookie
>>>>> would
>>>>> only be set if a user has explicitly changed the locale. That way we can
>>>>> remember a users preference even when the user is logged out.
>>>>>
>>>>> Are you seeing ui_locales not taking affect without a user having used
>>>>> the
>>>>> locale drop-down?
>>>>>
>>>>> On Mon, 13 Aug 2018 at 23:42, Johannes Knutsen <johannes at kodet.no>
>>>>> wrote:
>>>>>> Currently the LocaleHelper#getUserLocale chooses locale priority based
>>>>>> on the following order:
>>>>>>
>>>>>> 1. kc_locale query parameter
>>>>>> 2. Locale cookie
>>>>>> 3. User profile
>>>>>> 4. ui_locales query parameter
>>>>>> 5. Accept-Language http header
>>>>>>
>>>>>> We are building clients which uses the ui_locales parameter to select
>>>>>> localization of the login to match the locale of the client.
>>>>>> Since the locale cookie has a higher priority than the ui_locales
>>>>>> query parameter, the ui_locales query parameter is ignored for any
>>>>>> auth requests with a kc_locale cookie present.
>>>>>>
>>>>>> 1. Do you see any implications of prioritizing the ui_locales
>>>>>> parameter above the locale cookie when resolving locale?
>>>>>> 2. Are there reasons why the ui_locales does not update the locale
>>>>>> cookie value the same way kc_locale parameter does it?
>>>>>>
>>>>>> Best regards,
>>>>>> Johannes Knutsen
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev