Blank page when redirect to <domain>.auth0.com/u/login

Get Help
21

Same problem here, this is currently a Go-Live blocker for us.

22

Hey there everyone and I sincerely apologize for the delay in responding to this Community topic. I can understand how frustrating experience a challenge like this can be.

To help each one of you move forward from this challenge you’re facing, I would like you to please send me a direct message with a HAR file capture of the events leading up to the blank page redirect paired with your tenant name. Please be sure to select “Preserve log” to catch redirects and scrub the file of user passwords before passing.

From there we can dive into what may be occurring in this situation and provide a better path way towards resolution. Please let me know if you have any questions in regards to this. Thank you in advance!

24

I tried to do capture a HAR file, but when the dev tools are open I can’t seem to replicate the issue.
When getting a blank page it seems like resizing the windows fixes the issue (see attached gif)

resize
resize1200×723 746 KB
.

2 Likes
26

Hi all,

I am going to try and work through this issue and find a resolution. Does anyone have steps to reproduce this?

It sounds like this isn’t limited to the SPA SDK, but lets start there. Can you provide a code snippet with anything related? Can you also DM me the name of your tenant so I can take a look at your tenant settings.

Thanks,
Dan

27

We think we have found the cause (and solution to) the problem with the blank login page.

For us it was due to a getTokenSilently being called multiple times before the redirect to the login pages hade completed.

More specifically getTokenSilently is first triggered behind the scenes when createAuth0Client is called and then we had a request middleware that called getTokenSilently on each API request to be able to add the token to an authorization header.

The problem with blank login pages seems to be fixed by waiting to initialise our request middleware until isAuthenticated == true, this way we prevent any explicit calls to getTokenSilently until we’re already authenticated and thus no longer have multiple calls before the redirect to login.

Hope this helps!

4 Likes
28

Thanks for the update @markus2!

Is anyone else able to get this working to solve the problem?

1 Like
29

It’s still a very strange bug that should probably be looked into from Auth0’s end, to at least add some sort of helpful error message if it occurs.

I think it should be quite easy to reproduce by just calling getTokenSilently directly after createAuth0Client :slight_smile:

1 Like
30

@markus2,

I tried to set this up by doing a call to getTokenSilently() after my createAuth0Client function. It throws an error, which doens’t let the login button load, but I think that would be expected.

Do you have a repo I could look at?

1 Like
31

We started seeing this a few weeks ago. A few observations:

  • it only happens in chrome
  • not all apps are affected
  • it does not happen with the auth0 sample app for the SDK
  • it does not happen when I disable this flag in chrome: chrome://flags/#enable-paint-holding
32

@josh.oberdick do you have a repository we could investigate where it’s occurring? If you are able to recreate it can you get @dan.woda and I a HAR file capture and direct message us it so we can see what we can uncover from there. Thanks in advance!

33

Hey @James.Morrison and @dan.woda, I just sent you a HAR file as requested. Hope it helps to resolve this issue.

34

Thanks @patrick.breiter. We will keep you posted as we take a look.

35

We reviewed the HAR file you sent over @patrick.breiter but did not find anything that would point us in a specific direction in our investigation. We are continuing to troubleshoot this challenge and will let you know what we find. Thank you.

1 Like
36

I found out that it only happens when I have an ad-blocker active in Chrome or if I use the Brave browser (based on Chromium which disables ads and trackers). Try to install the AdBlock-Plus extension in Chrome and make sure it is activated when you are being redirected to the login page. Hope this helps.

1 Like
37

Hi @patrick.breiter,

I tried using ABP and it didn’t seem to cause any issues with the login page you linked in your DM. (I typically have ABP active with default settings and it hasn’t caused issues for me in the past).

I also looked at your HAR and it looks like you are calling /authorize then immediately calling it again, but as a silent login request the second time. Can you post your code that makes the requests?

38

getTokenSilently() being called before the user is authenticated seems to be our issue too. Fixed it by deferring api calls till isAuthenticated == true. Thank you for the solution.

1 Like
39

I have this exact same behavior, can we get a resolution for this???

40

I had the same issues and I fixed it add a delay in Guard class

private redirectIfUnauthenticated(
    state: RouterStateSnapshot
  ): Observable<boolean> {
    return this.auth.isAuthenticated$.pipe(
      delay(100),
      tap((loggedIn) => {
        if (!loggedIn) {
          this.auth.loginWithRedirect({ appState: { target: state.url } });
          return of(false);
        } else {
          return of(true);
        }
      })
    );
  }
2 Likes
41

Thank you for sharing your solution @hcastillo.mendoza!

1 Like
42

Hi, thank you for the effort.
I don’t use the spa SDK but the old way for javascript(auth0-js@9.11.3).
The bug is reproduced in production just by calling authorize() - I don’t use the SDK before this call at all.
As mentioned before, resizing of the screen solves this problem.
I don’t think this bug can be closed…

2 Likes