Re: [keycloak-dev] ui_locales query parameter?

On 4/17/2018 1:59 PM, Stian Thorgersen wrote: > For the account management console I think the correct approach is the > following: > > * Add an endpoint to account management service to allow setting the > user locale which the account management should call - it should not > re-direct to login back and do the whole login dance > * Change the way the account management console loads the messages - > it should load using a rest endpoint, not by injecting into the > index.ftl. That allows re-loading messages if the locale is changed > without having to do the login dance What is it about the "login dance" that causes a problem?  It seems to do exactly what I need it to do, as long as I can pass in kc_locale.

> > > On 17 April 2018 at 15:59, Marek Posolda <mposolda(a)redhat.com > <mailto:mposolda@redhat.com>> wrote: > > On 17/04/18 15:00, Stan Silvert wrote: > > On 4/16/2018 1:51 PM, Stian Thorgersen wrote: > > kc_locale is only aimed at internal use. You should use > ui_locales > that's the publicly available param. > > The problem is that I need the server-side logic associated with > kc_locale.  kc_locale will update the cookie and update the > UserModel. > ui_locales is just a pass-through back to the application. > > So we can either add kc_locale as a login param in keycloak.js > or we can > add the server-side logic to ui_locales.  The simplest is to > do the > former.  But perhaps we should have been doing the latter all > along? > > IMO the ui_locales parameter shouldn't update the UserModel. It's > possible that there would be 2 different applications and both of > them will send different values of ui_locales parameter. In that > case, when user switch between application1 and application2 (on > each SSO login), there will be update to UserModel, which is not > good regarding performance IMO. > > I can see in LocaleHelper.getUserLocale that the order about how > the locale is resolved is: > 1. kc_locale parameter > 2. KEYCLOAK_LOCALE cookie > 3. UserModel attribute > 4. ui_locales query parameter > 5. Accept-Language header > > Is this order proper or not? AFAIK the first 3 items are used just > if user explicitly selects the language on Keycloak login screen > (or account mgmt screen). If we put ui_locales up, we will defacto > give the control to application to override the localization, > which user explicitly chosen on login screen. Do we want to do > that? Is it good regarding usability? I think that not, but maybe > I am wrong... > > > I think the current order is correct. > > 1. Change locale if user has explicitly made the change - kc_locale > should only be set when the user changes it manually through login pages > 2-3 Tries to figure out the users last pick > 4. Provided by the application as a hint for what locale the user may > want. It should not override the users explicitly set locale > 5. Accept-Language is supposed to give the users preferred locale. > However, this is often wrong and just defaults to en. Hence why it > comes last. > > There's been quite a lot of discussion to get this right in the past, > so I'm quite confident that the current logic works and it has been > confirmed by a surprising amount of folks. Well it was tweaked quite a > few times based on user feedback. > > > Marek > > > On 16 April 2018 at 16:06, Stan Silvert > <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com> > <mailto:ssilvert@redhat.com <mailto:ssilvert@redhat.com>>> > wrote: > >      OK. > >      Does anyone object to adding kc_locale to the login > options on the >      keycloak.js adapter? > > > >      On 4/16/2018 2:45 AM, Stian Thorgersen wrote: > >      It's a query param defined by OpenID Connect. See > http://openid.net/specs/openid-connect-core-1_0.html > <http://openid.net/specs/openid-connect-core-1_0.html> > >  <http://openid.net/specs/openid-connect-core-1_0.html > <http://openid.net/specs/openid-connect-core-1_0.html>>;. > It allows >      the application to pass a list of req locales in > case the >      application knows it. > >      When doing the redirect login flow the > applications should use >      ui_locales. kc_locale is an internal param and > should really only >      be used by the locale switcher on the login screen. > >      On 16 April 2018 at 02:44, Stan Silvert > <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com> >      <mailto:ssilvert@redhat.com > <mailto:ssilvert@redhat.com>>> wrote: > >          Does anyone know what ui_locales is actually > used for? > >          I can't find usages except for in the testsuite. > >          The query param used to change locale is > kc_locale.  Should >          ui_locales >          deprecated? > >          Stan > >          _______________________________________________ >          keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> >          <mailto:keycloak-dev@lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > <https://lists.jboss.org/mailman/listinfo/keycloak-dev> > >  <https://lists.jboss.org/mailman/listinfo/keycloak-dev > <https://lists.jboss.org/mailman/listinfo/keycloak-dev>> > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > <https://lists.jboss.org/mailman/listinfo/keycloak-dev> > > > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev