[keycloak-dev] ui_locales query parameter?
Stan Silvert
ssilvert at redhat.com
Wed Apr 18 10:23:35 EDT 2018
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>
>>
>>
>
>
More information about the keycloak-dev
mailing list