[keycloak-dev] keycloak-dev Digest, Vol 58, Issue 16
Stian Thorgersen
sthorger at redhat.com
Thu Apr 19 15:21:15 EDT 2018
This is really a question for the user mailing list and not the developer
mailing list.
In either case the answer is simple. Some methods in the admin client
return a Response object. You need to call close on that. Otherwise the
connection won't be released back into the pool.
On 19 April 2018 at 15:07, Hafiz Syed Umer Ahmed <umer at codexnow.com> wrote:
> Hi,
>
> I am using keycloak 3.4.1 final on docker with PostgreSQL. I have written a
> spring boot application using keycloak admin client. The problem i am
> facing is that when i make several request on a particular api for example
> creating a user in keycloak it gets halt and does not respond.
> For example : Create user api
> after 10 successful request it does not process the 11th request and
> postman or restlet client shows "sending request" . After halting state it
> does not process any other api request until and unless i restart my spring
> boot application. I am not getting what is the issue. I have checked all
> the credentials and my application settings as well. Is there any rate
> limit on api calling in keycloak or there is some other issue ??
>
> Regards
>
> Umer
>
> On Wed, Apr 18, 2018 at 5:38 PM, <keycloak-dev-request at lists.jboss.org>
> wrote:
>
> > Send keycloak-dev mailing list submissions to
> > keycloak-dev at lists.jboss.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > or, via email, send a message with subject or body 'help' to
> > keycloak-dev-request at lists.jboss.org
> >
> > You can reach the person managing the list at
> > keycloak-dev-owner at lists.jboss.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of keycloak-dev digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Application and server in separate networks (Christian Beikov)
> > 2. Re: ui_locales query parameter? (Stian Thorgersen)
> > 3. Re: ui_locales query parameter? (Stan Silvert)
> > 4. Re: ui_locales query parameter? (Stian Thorgersen)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Wed, 18 Apr 2018 13:45:06 +0200
> > From: Christian Beikov <christian.beikov at gmail.com>
> > Subject: [keycloak-dev] Application and server in separate networks
> > To: keycloak-dev <keycloak-dev at lists.jboss.org>
> > Message-ID: <41e1a805-cc38-50cf-f794-cda6afd49313 at gmail.com>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > Hi,
> >
> > is it necessary that an application secured by Keycloak can access the
> > Keycloak server? Or is it enough if the Browser can access the Keycloak
> > server?
> >
> > --
> >
> > Mit freundlichen Gr??en,
> > ------------------------------------------------------------------------
> > *Christian Beikov*
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Wed, 18 Apr 2018 13:46:25 +0200
> > From: Stian Thorgersen <sthorger at redhat.com>
> > Subject: Re: [keycloak-dev] ui_locales query parameter?
> > To: Stan Silvert <ssilvert at redhat.com>
> > Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> > Message-ID:
> > <CAJgngAeShg4HZL5tTR-zvziKYeBU3-gQ3S4t+DU-_uwDKvO_
> > 4w at mail.gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > 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.
> >
> > On 18 April 2018 at 01:17, Stan Silvert <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>> 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
> > >>>
> > > >> 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
> > > >>.
> > > >> 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>>> 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>>
> > > >> 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
> > > > 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
> > >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 18 Apr 2018 08:19:58 -0400
> > From: Stan Silvert <ssilvert at redhat.com>
> > Subject: Re: [keycloak-dev] ui_locales query parameter?
> > To: stian at redhat.com
> > Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> > Message-ID: <c78a0305-d893-7fd6-e14a-2445cc983238 at redhat.com>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > 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>
> > >
> > >
> >
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Wed, 18 Apr 2018 14:37:41 +0200
> > From: Stian Thorgersen <sthorger at redhat.com>
> > Subject: Re: [keycloak-dev] ui_locales query parameter?
> > To: Stan Silvert <ssilvert at redhat.com>
> > Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> > Message-ID:
> > <CAJgngAeSuTouzjuAqAS3mCrQMGt9on090qUe90qvA452PS72kQ at mail.
> > gmail.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > 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.
> >
> > On 18 April 2018 at 14:19, Stan Silvert <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> 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>> 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
> > >> >>>
> > >> >> 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/open
> > >> id-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>>> 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>>
> > >> >> https://lists.jboss.org/
> > mailman/listinfo/keycloak-dev
> > >> >> <https://lists.jboss.org/mailm
> > >> an/listinfo/keycloak-dev>
> > >> >>
> > >> >> <https://lists.jboss.org/mail
> > >> man/listinfo/keycloak-dev
> > >> >> <https://lists.jboss.org/mailm
> > >> an/listinfo/keycloak-dev>>
> > >> >>
> > >> >>
> > >> >>
> > >> >> _______________________________________________
> > >> >> keycloak-dev mailing list
> > >> >> keycloak-dev at lists.jboss.org <mailto:
> keycloak-dev at lists.jbo
> > >> ss.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
> > >>
> > >>
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> 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
> >
> > End of keycloak-dev Digest, Vol 58, Issue 16
> > ********************************************
> >
> _______________________________________________
> 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