[keycloak-dev] Locale cookie vs ui_locales priority

[Marek Posolda]

+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?

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