New Universal login flow not reflecting introduction of new `connectionTypes` env vars

Hi there,

Our (React) app has recently changed its login to use the new universal flow with a customised login HTML template. This customised template paints the form differently based on the connectionTypes that get passed into the <Auth0Provider />

Some pseudo-code:

const connections = process.env.REACT_APP_AUTH0_CONNECTIONS;
return (
      ... >

The issue is that, even though these env vars are present in the most recent deployment of the application, they don’t appear to be present during the login screen. It feels like the login page is getting cached, so the newly introduced variables aren’t there. Normally I’d assume that the problem is on our side, but we are invalidating the S3 distribution as part of our deployment process, so it’s not the React app that’s cached.

Opening the application in incognito shows the expected behaviour and the environment variables are present during the login stage. Is it possible that on the initial load of the application it redirects to a cached version of the Auth0 login screen? Is there a way to avoid this?



Are you seeing the issue persist in your non-incognito browser if you refresh the page with a cleared cache (i.e. CMD + Shift + R on Mac).

If the issue persists after this, we can generally assume it’s not a browser caching problem.

Also to be clear, it sounds like you are using Classic Universal Login, as you are customizing the HTML template in the dashboard which is not a New Universal Login feature. Please let me know if I am mistaken.

Hi @dan.woda,

Thanks for the response.

TL;DR - It was user error (of course). I’ll post what I found out anyway, in case it’s useful to anyone else.


The issue does persist in non-incognito browsers after a hard refresh.

Also you’re correct in that we’re using a custom template. I only just noticed the warning on the universal login page: “One or more pages are using custom HTML to override the Universal Login experience.” I’ve edited the question tags to reflect that.

The issue disappeared after a day, but I can reproduce it if I change the login URL query params to remove the value from the connectionTypes parameter:




We had some code in the custom HTML template which uses the nullish coalescing operator to provide a default value if the connectionTypes parameter is missing, but this fails if it is empty because an empty array is not nullish.

currentUrl.searchParams.get('connectionTypes')?.split(',') ?? ['email-password'];

As for why the connectionTypes appeared empty in the URL in the first place, that’s still a mystery. But for now, this issue is solved.

Thanks a lot!

Great to hear it! Thank you for posting a thorough resolution too!