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#AuthorizationEndpoin...;.
(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(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
>
>