-
Bug
-
Resolution: Done
-
Undefined
-
None
-
False
-
-
False
-
-
Before reporting an issue
[X] I have searched existing issues
[X] I have reproduced the issue with the latest release
Area
token-exchange
Describe the bug
In my case an execute-actions-email is sent to a user for them to update their password. After the user clicks on the link in the execute-action-email they will visit an infopage listing the actions to execute followed by the update-password-page. The infopage is translated according to the locale accepted by the browser-request but update-password-page is translated according to the locale set in the user's profile.
If these two locales are not equal the translation changes during the workflow.
Version
20.0.5
Expected behavior
The first page should be translated by the user's locale aswell.
Actual behavior
The first page and the second page are translated differently if the browser-requested locale and the user-profile's locale are not equal.
How to Reproduce?
precondition:
- a realm with a working smtp config and two supported languages (for example: german and english)
- a browser without a cookie specifying a locale for keycloak that is set to one of the supported languages (for example: german)
1. create a user with a specific locale (for example: english)
2. trigger an execute-actions-email for the UPDATE_PASSWORD action
3. the email is in english
4. open the link send by mail in the browser
5. the infopage will open in german, the language accepted by the browser
6. the following update-password-page will open in englisch, the use-profile's locale
Anything else?
I might have already identified the underlying issue: the authenticed user is not loaded into the loginformsprovider in ExecuteActionsActionTokenHandler::handleToken.
I plan to provide a pull-request shortly.
- links to