Re: [keycloak-dev] ui_locales query parameter?

Not sure it should be added directly to keycloak.js as it's not strictly a supported param. Either you should just use it from keycloak.js, but not make it a direct option, or we should add it as a supported param. In the latter case we should probably document it.

On 18 April 2018 at 14:19, Stan Silvert <ssilvert(a)redhat.com <mailto:ssilvert@redhat.com>> wrote: On 4/18/2018 7:46 AM, Stian Thorgersen wrote: > I don't think it has to be done the way I propose so I don't see > a strong need to change it. As long as it works with kc_locale > that's fine. OK.  I'll add the kc_locale param to keycloak.js. It might be useful for others as well. > > On 18 April 2018 at 01:17, Stan Silvert <ssilvert(a)redhat.com > <mailto:ssilvert@redhat.com>> wrote: > > On 4/17/2018 3:07 PM, Stan Silvert wrote: > > 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. > I was thinking that I actually need the redirect in order to > re-initialize the welcome screen's localized text.  The > welcome screen > uses FreeMarker for localization.  But you can't get back to > the welcome > screen without logging out, so logout's redirect would take > care of the > re-initialization of the welcome screen. Therefore, adding an > endpoint > and reloading the messages in Angular would work. > > A new endpoint for this would: > * Set the cookie to the new locale > * Set the UserModel to the new locale > * Return the localized message bundle > > Then I would have to refactor all the language handling on > the Angular > side.  It would all just take a bit of time to implement. But > if you > really think it has to be done that way we can do it. > > > > >> > >> > >> On 17 April 2018 at 15:59, Marek Posolda > <mposolda(a)redhat.com <mailto:mposolda@redhat.com> > >> <mailto:mposolda@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>> > >>              <mailto:ssilvert@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>> > >> > >>                  >  <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>> > >>  <mailto:ssilvert@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>> > >>  <mailto:keycloak-dev@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>> > >> > >>                  >  <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> > <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 > <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > <https://lists.jboss.org/mailman/listinfo/keycloak-dev> > >