Email link authentication doesn't correctly encode return URL containing a #

[rich-j]

The new email link auth feature #359 looks promising. However, it doesn't redirect back properly to a Dart Angular app that uses "hash routing" during development. Our testing signin link is:

http://localhost:8080/#/signin?server=local9090&index=0

the authentication link received in email:

https://test-xxx.firebaseapp.com/__/auth/action?apiKey=XXX&mode=signIn&oobCode=XXX&continueUrl=http://localhost:8080/?ui_sid%3DMpN83UThtkHRx3Z9ZWyu3L3OpaqMsPye%26ui_sd%3D0%23/signin?server%3Dlocal9090%26index%3D0&lang=en

The above link doesn't correctly return the application to the state needed to continue the signin.

Building in a mode that doesn't use "hash routing" gives us a link (note - no # before "signin"):

http://localhost:8080/signin?server=local9090&index=0

and the resulting email link:

https://test-xxx.firebaseapp.com/__/auth/action?apiKey=XXX&mode=signIn&oobCode=XXX&continueUrl=http://localhost:8080/signin?server%3Dlocal9090%26index%3D0%26mode%3Dselect%26ui_sid%3D6ZdYpaLTHKv5aO9tzVmRPSwmVBg3MsNB%26ui_sd%3D0&lang=en

This link works to sign in.

It appears that the Firebase code that encodes the return redirect link doesn't correctly process links that contain a hash. I believe the same issue affects the redirect back from the account chooser credential helper.

• Operating System version: macOS Mojave 10.14.2
• Browser version: Google Chrome Version 71.0.3578.98 (Official Build) (64-bit)
• Firebase UI version: 3.5.1
• Firebase SDK version: 5.7.1

[wti806]

@rich-j We use google closure library to parse the URL and append the parameters needed for email link sign in. The parser treats everything after hashtag as URI fragment. And I think that is based on the URL spec. I'm not quite familiar with dart app. But as you mentioned, is not to use "hash routing" a reasonable workaround?

[bojeil-google]

I think email action codes are built on the premise that the parameters are passed via query string and not via hash fragment which makes this incompatible with hash routing.
Note that FirebaseUI uses history API to clear the URL query strings after the code is processed.

[rich-j]

@wti806 Yes, not using "hash routing" is reasonable. We don't use "hash routing" in production. The Dart dev server that is used during development doesn't support "deep linking" dart-lang/build#886 so you need "hash routing" to have automatic build/reload. This could also be an issue with Typescript Angular projects that use "hash routing".

I spent a few hours tracking down this issue so at least having this issue documented may help others.

[bojeil-google]

Documenting this makes sense. Note that, as I mentioned earlier, this applies to all out of band email action flows (email verification, password reset, etc) and not just email sign-in which is why this wasn't specifically called out for this FirebaseUI feature.