[keycloak-dev] ui_locales query parameter?
Marek Posolda
mposolda at redhat.com
Wed Apr 18 11:29:53 EDT 2018
Fyi. I've created https://issues.jboss.org/browse/KEYCLOAK-7192 for the
better support of "ui_locales" parameter. Probably not directly related
to this, but I found that issue when looking at this (and specially at
LocaleHelper class).
Marek
On 18/04/18 16:23, Stan Silvert wrote:
> 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 at redhat.com
>> <mailto:ssilvert at 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 at redhat.com
>>> <mailto:ssilvert at 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 at redhat.com <mailto:mposolda at redhat.com>
>>> >> <mailto: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>>
>>> >> <mailto: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>>
>>> >>
>>> >>
>>> <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>>
>>> >> <mailto: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>>
>>> >> <mailto: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>>
>>> >>
>>> >>
>>> <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>
>>> <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>
>>>
>>>
>>> _______________________________________________
>>> 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
More information about the keycloak-dev
mailing list