[keycloak-dev] ui_locales query parameter?

Tue Apr 17 11:32:23 EDT 2018

On 4/17/2018 10:05 AM, Marek Posolda wrote:
> 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
Here is what the spec says:

Preferred Locales
    OPs MUST support requests for preferred languages and scripts for
    the user interface and for Claims via the ui_locales and
    claims_locales request parameters, as defined in Section 3.1.2
    <http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint>.
    (Note that the minimum level of support required for these
    parameters is simply to have their use not result in errors.) 

I think you are correct that Keycloak doesn't actually do anything with 
the ui_locales param except to possibly use it as the Locale for that 
one request.  We don't throw an error, so I guess we meet the minimum 
level of support?

It looks like kc_locale does what ui_locales was intended for. But the 
spec does not tell us exactly what the IDP must do when it sees ui_locales.

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