It's a query param defined by OpenID Connect. See 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>> 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> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>

kc_locale is only aimed at internal use. You should use ui_locales that's the publicly available param.

On 16 April 2018 at 16:06, Stan Silvert <ssilvert(a)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>;. 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>> 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> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > <https://lists.jboss.org/mailman/listinfo/keycloak-dev> > >

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...

Marek > >> On 16 April 2018 at 16:06, Stan Silvert <ssilvert(a)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>;. 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>> 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> >>> 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

On 17/04/18 15:59, Marek Posolda 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 noticed one more thing, that LocaleHelper is reading just the ui_locales parameter. This is not good as the ui_locales parameter is available just in very 1st request sent to the login screen, but not in subsequent requests. So for example I think that current flow is like this: - Application sent parameter "ui_locales=cs" - Login page is displayed in czech language (assuming user did not explicitly set locale before and hence his userModel doesn't have filled locale). This is correct behaviour - User filled username/password. Now the TOTP page (or any requiredActions page for example) is shown. But it is shown in default locale as ui_locales query parameter is not available anymore. It is just in very 1st request to login screen. This is not correct behaviour IMO. The locale "cs" should be used for the rest of whole login session. Am I correct that this workflow is broken? If yes, the solution might be to add locale as the note to AuthenticationSessionModel . And then use the note from AuthenticationSessionModel in LocaleHelper instead of ui_locales query parameter. Marek > > Marek > >> >>> On 16 April 2018 at 16:06, Stan Silvert <ssilvert(a)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>;. 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>> 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> >>>> 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 > >

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

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>

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>> 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 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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&gt; 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>> 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/open > id-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/mailm > an/listinfo/keycloak-dev> > >> > >> <https://lists.jboss.org/mail > man/listinfo/keycloak-dev > >> <https://lists.jboss.org/mailm > an/listinfo/keycloak-dev>> > >> > >> > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jbo > ss.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 > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

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