Re: [keycloak-dev] ui_locales query parameter?

On 4/18/2018 8:37 AM, Stian Thorgersen wrote: > 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. Yes, I'm proposing that we add it, support it, and document it. I don't know how I can use it without adding it as an option. > 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> >> >> > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev