Firebase CLI prompts users to set a rewrite rule for SPAs.
"rewrites": [
{
"source": "**/!{*.*}",
"destination": "/index.html"
}
]
Email verification, email change notification emails and password reset emails all use the __/auth/action paths. These auth action urls forward to index.html given the SPA rewrite rule.
And can anyone who knows Firebase glob patterns figure out some way to exclude paths beginning in __ from the rewrite?
After much glob debugging, I finally dug into Superstatic and figured out that the following rewrite rules fix the problem:
"rewrites": [
{
"source": "/__/auth/action",
"destination": "/__/auth/action"
},
{
"source": "**",
"destination": "/index.html"
}
]
I propose that all firebase.json rewrite rules come with the /__/auth/action rule baked in. Or add an option to Superstatic to ignore rewrites on /__* paths and keep that option on by default.
Are you experiencing this in production? Because the reserved routes take precedence over all user-supplied content. You will see this happen locally (because the auth actions are not served locally by superstatic) but in general you shouldn't be pointing your authDomain to localhost.
@mbleigh I am seeing it in production :(
I noticed it when I had trouble with https://quiver-two.firebaseapp.com/. I was setting up auth and verifying email addresses. Every time I'd click on the (link in the email)[https://quiver-two.firebaseapp.com/__/auth/action?mode=verifyEmail&oobCode=_EEj-KeV-FDeETmeRA_KDX0RY5s&apiKey=AIzaSyBP5EaFCQ0yAbcvYozyKCwKJ2Wf-yioCs4] I'd get 404'd.
Adding in the extra rewrite rule mentioned above was the only solution.
We'll take a look and see if we can repro and figure out what's happening.
@mbleigh Please do look into this. I'm experiencing similar issues for user logins. My popup authentification window serves up index.html unless the rules are modified. This is on production (with and without custom domains).
Do you have a service worker that has its own rewrite logic? The /__/auth/* reserved URLs take precedence over user-supplied rewrites (I double-confirmed that today), but if you have a service worker doing its own rewriting that could explain the issue.
Ok, its seems the service worker was intercepting the requests.
Fixed it by adding a navigateFallbackWhitelist property to sw-precache-config.js:
module.exports = {
staticFileGlobs: [
'/index.html',
'/manifest.json',
'/bower_components/webcomponentsjs/webcomponents-lite.min.js',
],
navigateFallback: 'index.html',
navigateFallbackWhitelist: [/^(?!\/__)/]
};
Also note that what I said about it affecting custom and non-custom domains was wrong (after more testing). Localhost and custom domains work fine; the problem only occurs on firebaseapp.com sub-domains but can be fixed with the above configuration.
For reference, this sounds like the same or similar issue, with a similar solution of adding navigateFallbackWhitelist to service worker configuration: https://github.com/Polymer/polymer-cli/issues/290.
I suppose there isn't any other way that /__* reserved URLs can override service worker rules, short of whitelisting in sw config?
Closing as this was not a CLI issue.
Most helpful comment
Ok, its seems the service worker was intercepting the requests.
Fixed it by adding a navigateFallbackWhitelist property to sw-precache-config.js:
Also note that what I said about it affecting custom and non-custom domains was wrong (after more testing). Localhost and custom domains work fine; the problem only occurs on firebaseapp.com sub-domains but can be fixed with the above configuration.