search

okta / okta-signin-widget

HTML/CSS/JS widget that provides out-of-the-box authentication UX for your organization's apps
Other
375 stars 320 forks source link

Error messages not translated #1708

Open cloeffl opened 3 years ago

cloeffl commented 3 years ago

I'm submitting a

Background info

Our website's primary language is english. Therefore we are forced the language of the Sing In Widget to be english. If you try to sign in with wrong credentials the displayed error message is in the language of the user's browser and not translated.

Expected behavior

The error message should be translated using the defined translations.

What went wrong?

Error message in case of wrong credentials is generated by the backend service and using the browser language. The received error is not handled using the i18n translations.

Steps to reproduce

Set the widget language to another language than your browsers language. Try to sign in with wrong credentials.

Your environment

denysoblohin-okta commented 3 years ago

Thank you for submitting this issue. However, I can't reproduce your problem with SIW 5.3.2 or 5.4.0 If I set language: 'de' in SIW config and try to login with wrong credentials, displayed error message will be Anmelden nicht möglich (taken from i18n file in SIW)

/api/v1/authn request will end with E0000004 error and response will be

{"errorCode":"E0000004","errorSummary":"Authentifizierung fehlgeschlagen","errorLink":"E0000004","errorId":"oae331MtqP5S5uZdIDPXSCcrQ","errorCauses":[]}

errorSummary in response is translated by backend because of request header accept-language: de (and will be overridden by SIW's error translation)

Can you please provide the exact error message you get in SIW and also copy of your request to /api/v1/authn

cloeffl commented 3 years ago

I tried around and I think I found the cause. We are passing an instance of OktaAuth using the authClient option. After doing this the request header looks like this:

Accept: application/json
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 146
Content-Type: application/json
Cookie: DT=DI0xoXI9NrmQl2QX4qLzNrz2A; enduser_version=1
Host: login-dev.sartorius.com
Origin: http://localhost:1234
Pragma: no-cache
Referer: http://localhost:1234/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.190 Safari/537.36
X-Okta-User-Agent-Extended: @okta/okta-react/4.1.0 okta-auth-js/4.7.1

After setting the authClient option the X-Okta-User-Agent changes and the bug occurs. So with the authClient set the Accept-Language header is no longer containing the chosen language.

aarongranick-okta commented 3 years ago

@cloeffl Thank you for the detailed information. Our engineers will investigate this issue. Internal ref: OKTA-375055

Is it possible as a workaround to avoid using the authClient and use authParams instead?