[keycloak-dev] ui_locales query parameter?

Stan Silvert ssilvert at redhat.com
Tue Apr 17 15:07:14 EDT 2018


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 at redhat.com 
> <mailto:mposolda at 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 at redhat.com <mailto:ssilvert at redhat.com>
>             <mailto:ssilvert at redhat.com <mailto:ssilvert at 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 at redhat.com <mailto:ssilvert at redhat.com>
>                      <mailto:ssilvert at redhat.com
>                 <mailto:ssilvert at 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 at lists.jboss.org
>                 <mailto:keycloak-dev at lists.jboss.org>
>                          <mailto:keycloak-dev at lists.jboss.org
>                 <mailto:keycloak-dev at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>
>



More information about the keycloak-dev mailing list