Uploaded image for project: 'Red Hat build of Keycloak'
  1. Red Hat build of Keycloak
  2. RHBK-2661

the InfoPage after an ExecuteActionsEmail is not localized based on the user's locale [GHI#17233]

XMLWordPrintable

    • False
    • Hide

      None

      Show
      None
    • 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.

              Unassigned Unassigned
              pvlha Pavel Vlha
              Keycloak Core IAM
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: