[keycloak-dev] Locale cookie vs ui_locales priority

Fri Aug 24 04:46:52 EDT 2018

Thanks for the input!
I will create a Jira for the feature and submit a PR after doing some
adjustments according to your comments.

Not sure about the configuration support. I tend to agree with Stan
and prefer to have a sane default without configuration support.
Special cases probably will not be supported by configuration alone
anyways. At least I think it should be a separate feature request.
On Wed, Aug 22, 2018 at 2:06 PM Stan Silvert <ssilvert at redhat.com> wrote:
>
> 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
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev