8:07 a.m.
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(a)lists.jboss.org>
wrote:
Send keycloak-dev mailing list submissions to
keycloak-dev(a)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(a)lists.jboss.org
You can reach the person managing the list at
keycloak-dev-owner(a)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(a)gmail.com>
Subject: [keycloak-dev] Application and server in separate networks
To: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Message-ID: <41e1a805-cc38-50cf-f794-cda6afd49313(a)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(a)redhat.com>
Subject: Re: [keycloak-dev] ui_locales query parameter?
To: Stan Silvert <ssilvert(a)redhat.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Message-ID:
<CAJgngAeShg4HZL5tTR-zvziKYeBU3-gQ3S4t+DU-_uwDKvO_
4w(a)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(a)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(a)redhat.com
> >> <mailto:mposolda@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(a)redhat.com <mailto:ssilvert@redhat.com>
> >> <mailto:ssilvert@redhat.com <mailto:ssilvert@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(a)redhat.com
<mailto:ssilvert@redhat.com>
> >> <mailto:ssilvert@redhat.com
> >> <mailto:ssilvert@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(a)lists.jboss.org
> >> <mailto:keycloak-dev@lists.jboss.org>
> >> <mailto:keycloak-dev@lists.jboss.org
> >> <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)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(a)redhat.com>
Subject: Re: [keycloak-dev] ui_locales query parameter?
To: stian(a)redhat.com
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Message-ID: <c78a0305-d893-7fd6-e14a-2445cc983238(a)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(a)redhat.com
> <mailto:ssilvert@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(a)redhat.com
> <mailto:mposolda@redhat.com>
> >> <mailto:mposolda@redhat.com
<mailto:mposolda@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(a)redhat.com
<mailto:ssilvert@redhat.com>
> <mailto:ssilvert@redhat.com <mailto:ssilvert@redhat.com>>
> >>? ? ? ? ? ? ? <mailto:ssilvert@redhat.com
> <mailto:ssilvert@redhat.com> <mailto:ssilvert@redhat.com
> <mailto:ssilvert@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(a)redhat.com
> <mailto:ssilvert@redhat.com> <mailto:ssilvert@redhat.com
> <mailto:ssilvert@redhat.com>>
> >>? ? ? ? ? ? ? ? ? ? ? ?<mailto:ssilvert@redhat.com
> <mailto:ssilvert@redhat.com>
> >>? ? ? ? ? ? ? ? ? <mailto:ssilvert@redhat.com <mailto:
ssilvert(a)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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org
>
> >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev@lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>>
> >>? ? ? ? ? ? ? ? ? ? ? ? ? ?<mailto:keycloak-dev@lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev@lists.jboss.org <mailto:
keycloak-dev(a)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(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> <mailto:keycloak-dev@lists.jboss.org
> <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@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(a)redhat.com>
Subject: Re: [keycloak-dev] ui_locales query parameter?
To: Stan Silvert <ssilvert(a)redhat.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Message-ID:
<CAJgngAeSuTouzjuAqAS3mCrQMGt9on090qUe90qvA452PS72kQ@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(a)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(a)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(a)redhat.com
>> >> <mailto:mposolda@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(a)redhat.com
<mailto:ssilvert@redhat.com>
>> >> <mailto:ssilvert@redhat.com
<mailto:ssilvert@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(a)redhat.com
<mailto:ssilvert@redhat.com>
>> >> <mailto:ssilvert@redhat.com
>> >> <mailto:ssilvert@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(a)lists.jboss.org
>> >> <mailto:keycloak-dev@lists.jboss.org>
>> >> <mailto:keycloak-dev@lists.jboss.org
>> >> <mailto:keycloak-dev@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(a)lists.jboss.org
<mailto:keycloak-dev@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(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
------------------------------
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
End of keycloak-dev Digest, Vol 58, Issue 16
********************************************
2:21 p.m.
New subject: keycloak-dev Digest, Vol 58, Issue 16
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(a)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(a)lists.jboss.org>
wrote:
> Send keycloak-dev mailing list submissions to
> keycloak-dev(a)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(a)lists.jboss.org
>
> You can reach the person managing the list at
> keycloak-dev-owner(a)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(a)gmail.com>
> Subject: [keycloak-dev] Application and server in separate networks
> To: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> Message-ID: <41e1a805-cc38-50cf-f794-cda6afd49313(a)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(a)redhat.com>
> Subject: Re: [keycloak-dev] ui_locales query parameter?
> To: Stan Silvert <ssilvert(a)redhat.com>
> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> Message-ID:
> <CAJgngAeShg4HZL5tTR-zvziKYeBU3-gQ3S4t+DU-_uwDKvO_
> 4w(a)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(a)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(a)redhat.com
> > >> <mailto:mposolda@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(a)redhat.com
<mailto:ssilvert@redhat.com>
> > >> <mailto:ssilvert@redhat.com <mailto:
ssilvert(a)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(a)redhat.com
<mailto:ssilvert@redhat.com>
> > >> <mailto:ssilvert@redhat.com
> > >> <mailto:ssilvert@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(a)lists.jboss.org
> > >> <mailto:keycloak-dev@lists.jboss.org>
> > >> <mailto:keycloak-dev@lists.jboss.org
> > >> <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@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(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)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(a)redhat.com>
> Subject: Re: [keycloak-dev] ui_locales query parameter?
> To: stian(a)redhat.com
> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> Message-ID: <c78a0305-d893-7fd6-e14a-2445cc983238(a)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(a)redhat.com
> > <mailto:ssilvert@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(a)redhat.com
> > <mailto:mposolda@redhat.com>
> > >> <mailto:mposolda@redhat.com
<mailto:mposolda@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(a)redhat.com
<mailto:ssilvert@redhat.com>
> > <mailto:ssilvert@redhat.com <mailto:ssilvert@redhat.com>>
> > >>? ? ? ? ? ? ? <mailto:ssilvert@redhat.com
> > <mailto:ssilvert@redhat.com> <mailto:ssilvert@redhat.com
> > <mailto:ssilvert@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(a)redhat.com
> > <mailto:ssilvert@redhat.com> <mailto:ssilvert@redhat.com
> > <mailto:ssilvert@redhat.com>>
> > >>? ? ? ? ? ? ? ? ? ? ? ?<mailto:ssilvert@redhat.com
> > <mailto:ssilvert@redhat.com>
> > >>? ? ? ? ? ? ? ? ? <mailto:ssilvert@redhat.com <mailto:
> ssilvert(a)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(a)lists.jboss.org <mailto:keycloak-dev@lists.
jboss.org
> >
> > >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev@lists.jboss.org
> > <mailto:keycloak-dev@lists.jboss.org>>
> > >>? ? ? ? ? ? ? ? ? ? ? ? ? ?<mailto:keycloak-dev@lists.jboss.org
> > <mailto:keycloak-dev@lists.jboss.org>
> > >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev@lists.jboss.org
<mailto:
> keycloak-dev(a)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(a)lists.jboss.org
> > <mailto:keycloak-dev@lists.jboss.org>
> > <mailto:keycloak-dev@lists.jboss.org
> > <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@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(a)redhat.com>
> Subject: Re: [keycloak-dev] ui_locales query parameter?
> To: Stan Silvert <ssilvert(a)redhat.com>
> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> Message-ID:
> <CAJgngAeSuTouzjuAqAS3mCrQMGt9on090qUe90qvA452PS72kQ@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(a)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(a)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(a)redhat.com
> >> >> <mailto:mposolda@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(a)redhat.com
<mailto:ssilvert@redhat.com>
> >> >> <mailto:ssilvert@redhat.com <mailto:
ssilvert(a)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(a)redhat.com
<mailto:ssilvert@redhat.com>
> >> >> <mailto:ssilvert@redhat.com
> >> >> <mailto:ssilvert@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(a)lists.jboss.org
> >> >> <mailto:keycloak-dev@lists.jboss.org>
> >> >> <mailto:keycloak-dev@lists.jboss.org
> >> >> <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:
keycloak-dev(a)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(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> >
> >
>
>
> ------------------------------
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:15 p.m.
New subject: keycloak-dev Digest, Vol 58, Issue 16
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(a)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(a)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(a)lists.jboss.org>
> wrote:
>
> > Send keycloak-dev mailing list submissions to
> > keycloak-dev(a)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(a)lists.jboss.org
> >
> > You can reach the person managing the list at
> > keycloak-dev-owner(a)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(a)gmail.com>
> > Subject: [keycloak-dev] Application and server in separate networks
> > To: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> > Message-ID: <41e1a805-cc38-50cf-f794-cda6afd49313(a)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(a)redhat.com>
> > Subject: Re: [keycloak-dev] ui_locales query parameter?
> > To: Stan Silvert <ssilvert(a)redhat.com>
> > Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> > Message-ID:
> > <CAJgngAeShg4HZL5tTR-zvziKYeBU3-gQ3S4t+DU-_uwDKvO_
> > 4w(a)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(a)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(a)redhat.com
> > > >> <mailto:mposolda@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(a)redhat.com
<mailto:ssilvert@redhat.com>
> > > >> <mailto:ssilvert@redhat.com <mailto:
> ssilvert(a)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(a)redhat.com
<mailto:ssilvert@redhat.com
>
> > > >> <mailto:ssilvert@redhat.com
> > > >> <mailto:ssilvert@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(a)lists.jboss.org
> > > >> <mailto:keycloak-dev@lists.jboss.org>
> > > >>
<mailto:keycloak-dev@lists.jboss.org
> > > >> <mailto:keycloak-dev@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(a)lists.jboss.org
<mailto:keycloak-dev@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(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev(a)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(a)redhat.com>
> > Subject: Re: [keycloak-dev] ui_locales query parameter?
> > To: stian(a)redhat.com
> > Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> > Message-ID: <c78a0305-d893-7fd6-e14a-2445cc983238(a)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(a)redhat.com
> > > <mailto:ssilvert@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(a)redhat.com
> > > <mailto:mposolda@redhat.com>
> > > >> <mailto:mposolda@redhat.com
<mailto:mposolda@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(a)redhat.com
<mailto:ssilvert@redhat.com
>
> > > <mailto:ssilvert@redhat.com <mailto:ssilvert@redhat.com>>
> > > >>? ? ? ? ? ? ? <mailto:ssilvert@redhat.com
> > > <mailto:ssilvert@redhat.com> <mailto:ssilvert@redhat.com
> > > <mailto:ssilvert@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(a)redhat.com
> > > <mailto:ssilvert@redhat.com> <mailto:ssilvert@redhat.com
> > > <mailto:ssilvert@redhat.com>>
> > > >>? ? ? ? ? ? ? ? ? ? ? ?<mailto:ssilvert@redhat.com
> > > <mailto:ssilvert@redhat.com>
> > > >>? ? ? ? ? ? ? ? ? <mailto:ssilvert@redhat.com <mailto:
> > ssilvert(a)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(a)lists.jboss.org <mailto:keycloak-dev@lists.
> jboss.org
> > >
> > > >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev@lists.jboss.org
> > > <mailto:keycloak-dev@lists.jboss.org>>
> > > >>? ? ? ? ? ? ? ? ? ? ? ? ? ?<mailto:keycloak-dev@lists.
jboss.org
> > > <mailto:keycloak-dev@lists.jboss.org>
> > > >>? ? ? ? ? ? ? ? ? <mailto:keycloak-dev@lists.jboss.org
<mailto:
> > keycloak-dev(a)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(a)lists.jboss.org
> > > <mailto:keycloak-dev@lists.jboss.org>
> > > <mailto:keycloak-dev@lists.jboss.org
> > > <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@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(a)lists.jboss.org <mailto:keycloak-dev@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(a)redhat.com>
> > Subject: Re: [keycloak-dev] ui_locales query parameter?
> > To: Stan Silvert <ssilvert(a)redhat.com>
> > Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> > Message-ID:
> > <CAJgngAeSuTouzjuAqAS3mCrQMGt9on090qUe90qvA452PS72kQ@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(a)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(a)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(a)redhat.com
> > >> >> <mailto:mposolda@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(a)redhat.com
<mailto:ssilvert@redhat.com>
> > >> >> <mailto:ssilvert@redhat.com <mailto:
> ssilvert(a)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(a)redhat.com <mailto:
ssilvert(a)redhat.com>
> > >> >> <mailto:ssilvert@redhat.com
> > >> >> <mailto:ssilvert@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(a)lists.jboss.org
> > >> >> <mailto:keycloak-dev@lists.jboss.org>
> > >> >>
<mailto:keycloak-dev@lists.jboss.org
> > >> >>
<mailto:keycloak-dev@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(a)lists.jboss.org <mailto:
> keycloak-dev(a)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(a)lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> > >>
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> > >
> > >
> > >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2719
days inactive
2719
days old
2 comments
3 participants
participants (3)
-
Hafiz Syed Umer Ahmed -
Stian Thorgersen -
Thomas Darimont