Auth0-spa-js: localhost hosts file alias work around for user consent fails in auth0-spa-js

[yellowtailfan]

Your documentation offers a work around for user consent dialogs when developing on localhost by adding an alias for localhost to your local hosts file:

https://auth0.com/docs/api-auth/user-consent?_ga=2.215795216.600136371.1593852703-949282495.1585114689#skip-consent-for-first-party-applications

However, when I tried to implement this, I got an error saying "auth0-spa-js must run on a secure origin":

https://github.com/auth0/auth0-spa-js/blob/master/FAQ.md#why-do-i-get-auth0-spa-js-must-run-on-a-secure-origin

I would suggest updating your documentation to avoid recommending a work around that doesn't work.

Environment

• Version of auth0-spa-js used: @auth0/[email protected] via @auth0/[email protected]
• Which browsers have you tested in? Chrome for Windows
• Which framework are you using, if applicable (Angular, React, etc): React
• Other modules/plugins/libraries that might be involved: AWS Amplify

[stevehobbsdev]

Thanks @yellowtailfan. The documentation you refer to has a much wider scope than just this SDK as it covers all of our application types, not just SPAs.

This SDK does require to be run on a secure origin, so an origin that uses HTTPS or localhost. As soon as you add an alternative entry into the hosts file you violate that requirement, unless you also use some kind of local proxy to forward your HTTPS traffic. You can do this easily enough (Caddy is one option for doing this).

[yellowtailfan]

Thanks very much @stevehobbsdev for your helpful response. I hadn't noticed that https://*:* counts as a secure origin for the SPA library. So it sounds like we could:

1. Add app.local to our hosts file with the localhost IP address
2. Change our Auth0 Application settings from http://localhost:3000 to https://app.local:3000
3. Run our local development server on http://app.local:3000
4. Run a local server such as Caddy to proxy from http://app.local:3000 to https://app.local:3000

We are using Nextjs, so we could also look at serving from Nextjs to HTTPS directly via Express.

We've parked this issue for now, but this gives us some approaches to try when we come back to it in future. I'll leave this comment here in case it helps someone in a similar situation.