Hash get's lost on Safari/Webkit browsers

I created a custom login following this example:
https://github.com/auth0-samples/auth0-angular-samples/tree/embedded-login/02-Custom-Login-Form

The login works fine on IE, Edge, Chrome and Firefox, but on Safari/WebKit based browsers, it’s not working. I figuerd the hash, that is added to the callback url, is missing when the user gets redirected. So the following function does not work - there is no hash to parse:

  public handleAuthentication(): void {
    this.auth0.parseHash((err, authResult) => {
      if (authResult && authResult.accessToken && authResult.idToken) {
        alert('SUCCESSFULL');
      } else if (err) {
        alert(err.error + ' | ' + err.errorDescription);
      }
    });
  }

I wasn’t able to figure out why this is happening or how to fix it.
Any suggestions?

I have the same problem, specifically in Safari/Webkit browsers. Have you found a solution?

1 Like

BTW this only happens when deployed to server. When using react-scripts to run locally it works.

2 Likes

Have you found the solution?
I discovered this problem on a production server. Hash is returned successfully with Chrome, but with Safari - no. And it’s also missed with Chrome on iPhone.

1 Like

I have a similar problem. On Safari in Incognito mode, whenever finish authenticating on the Hosted Login, I get redirected back without a hash. Thus, parseHash returns an error: {error: "invalid_token", errorDescription: "Nonce does not match."}.

It works fine in Chrome (though sometimes I get the same bug, I just can’t reliably recreate it) and in regular Safari.

1 Like

Have you found the solution?
I discovered this problem on a production server. Hash is returned successfully with Chrome, but with Safari - no. And it’s also missed with Chrome on iPhone.

1 Like

I have a similar problem. On Safari in Incognito mode, whenever finish authenticating on the Hosted Login, I get redirected back without a hash. Thus, parseHash returns an error: {error: "invalid_token", errorDescription: "Nonce does not match."}.

It works fine in Chrome (though sometimes I get the same bug, I just can’t reliably recreate it) and in regular Safari.

1 Like

The problem is that Safari strips the hash part on redirects IF the hash is not preceded by a trailing slash. See this comment for a full description of the problem:

https://github.com/IdentityModel/oidc-client-js/issues/238#issuecomment-271105795

3 Likes

I also like to point out that in Safari 12, the redirectUri cannot include the filename.
For example:

http://localhost:5000/foohome WORKS
http://localhost:5000/foohom/ WORKS
http://localhost:5000/foohome.html/ **DOES NOT WORKS**
http://localhost:5000/foohome.html **DOES NOT WORKS**
3 Likes