[keycloak-dev] ui_locales query parameter?
Stan Silvert
ssilvert at redhat.com
Wed Apr 18 08:19:58 EDT 2018
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