[keycloak-dev] keycloak-dev Digest, Vol 58, Issue 16
Thomas Darimont
thomas.darimont at googlemail.com
Thu Apr 19 16:15:53 EDT 2018
This looks like as if you're not closing your admin client resources
(Responses) correctly.
Take a look at this:
https://gist.github.com/thomasdarimont/3082a1e480cd856b474c1c4498aa3788
Cheers,
Thomas
2018-04-19 21:21 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
> 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
> >
> _______________________________________________
> 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