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.
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>