Add a warning when auth emulator URI is set to localhost

[colohan]

[REQUIRED] Environment info

firebase-tools: 12.7.0

Platform: Windows 10

[REQUIRED] Test case

Any program which uses Firebase Auth, with the authentication emulator. My test case is here:

https://github.com/colohan/firebaseauth

[REQUIRED] Steps to reproduce

1. Run "firebase emulators:start".
2. Open the hosting emulator at http://127.0.0.1:5000 (using the link provided in a convenient table by the firebase emulator, if you like).
3. Click "click to sign in". This will use signInWithRedirect() to redirect you to the auth emulator at http://localhost:9099/emulator/auth/handler (with more params on the URL).
4. Click "+ Add new account", then click "Auto-generate user information", then click "Sign in with Google.com".
5. The emulator code will redirect you back to 127.0.0.1:5000
6. Notice that even though you just logged in -- you are not logged in.
7. Got to step 3, in an infinite loop.

[REQUIRED] Expected behavior

You get signed in.

[REQUIRED] Actual behavior

firebase-debug.log

You get an infinite loop, and are never signed in.

I'll include the logs, but the auth emulator doesn't appear to log anything, so I suspect they are useless.

firebase-debug.log

Analysis:

The actual problem: the emulator prompts you to go to 127.0.0.1:5000 in the command line output. But when you invoke signInWithRedirect(), it redirects you to localhost -- which the browser doesn't believe is the same as 127.0.0.1. So when you log in on localhost, and the emulator redirects you back to 127.0.0.1:5000, then sessionStorage is cleared, and your login session is lost.

There are three potential fixes to this issue that I can see:

1. Change the emulator command line to instruct the user to open http://localhost:5000 instead of http://127.0.0.1:5000. This fixes the problem if you do this. (It took me an embarrassingly long time to figure this out.)
2. Change the signInWithRedirect() to connect to the emulator through 127.0.0.1 instead of localhost, if that is what the user has already opened (I think this will work, but have not tested this change).
3. Identify some config option I've screwed up which is causing me to enter this bad edge case, and document it better or warn the user when they mess it up like I apparently did?

[joehan]

Hey @colohan, thanks for reporting this and sorry that you were affected by this. This seems similar to a class of issues we've seen before - we don't control the resolution algorithm for localhost, and on some machines, it resolves to the IPv6 localhost address ::1. Since not all of the emulators serve over IPv6, we've generally tried to fix these by specifying an IPv4 address instead of localhost.

In this case, the redirect address is specified in your code (https://github.com/colohan/firebaseauth/blob/main/web/src/index.js#L105), so its hard to fix on our end. However, I agree that a warning about using localhost is probably a good thing to add in this case.

[colohan]

Oooh, you are right about my code. Now I'm wondering where I copied that snippet of code from, because I just looked it up and your documentation and it says 127.0.0.1. BUT... that was changed from localhost back in June (after I wrote this code), so I'm not losing my mind.

So with that new documentation, fewer folks should hit this corner case, and that likely lowers the priority of fixing this.

Thank you!

[joehan]

Yep, you're definitely not the only one who's run into this issue, it is a subtle and tricky one. I'm gonna do a pass through the emulator docs & wipe any localhosts that are still there, so hopefully that saves some other folks headaches too.