Firebase-tools: HTTP functions path incorrectly prefixed with "/[firebase-project-idx][firebase-region]"

[tmcf]

Hi,

Firebase cloud functions run in the emulator have a request.path that is prefixed with [firebase-project-id][firebase-region]/ that is not present in live deployments. This causes functions that are request path sensitive (routing handlers via express or koa) to fail in the emulator while running ok live.

Either the emulator should set the HTTP triggers without this prefix or the prefix should be available in config/environment so the functions can handle the request path correctly.

Example live function deployment trigger URL:

• https://us-central1-fbfn-request-path.cloudfunctions.net/api-epsilon

Emulator trigger URL:

• http://localhost:5001/fbfn-request-path/us-central1/api-epsilon

[REQUIRED] Environment info

firebase-tools:
6.9.2

Platform:
macOS

[REQUIRED] Test case

Stackoverflow: https://stackoverflow.com/q/56091274/1974870
Github project showing issue: https://github.com/tmcf/fbfn-request-path
live firebase deploy (with expected results): https://fbfn-request-path.web.app

[REQUIRED] Steps to reproduce

1. Run live firebase app link above, functions report expected request path
2. Clone github project,
   
   
   
   • firebase emulators:start
   
   
   • firebase-debug.log
   
   
3. Visit emulator hosting page, functions report unexpected request path
   

[REQUIRED] Expected behavior

Emulator function request.url should be the same as live deployment request.url.

[REQUIRED] Actual behavior

Emulator function request.url path is prefixed with /[firebase-project-idx][firebase-region]/

[abeisgoat]

Great catch! We will get a fix for this in the next release.

[abeisgoat]

Fix is merged in, please re-open if you're still experiencing this once 6.9.3 is out.

[tmcf]

Thanks Abe!

[christiannaths]

Forgive me, but I think https://github.com/firebase/firebase-tools/commit/69e1e1bdce9506576754c448c5834e696207798a introduces some unexpected behaviour. As far as I can tell, there is now no way to get the _actual_ request path when running functions in the emulator.

I think this recommendation should have been implemented:

Either the emulator should set the HTTP triggers without this prefix or the prefix should be available in config/environment so the functions can handle the request path correctly.

For example, I need to generate an oauth callback url for the google OAuth2Client. I managed this before by using a combination of request.protocol, request.headers.host, and request.path. After this change–given that request.path no longer reflects the actual path, and the actual path is not stored anywhere–I'm at a loss as to how I can accomplish this without some hackery.

[samtstern]

@christiannaths that's interesting thanks for noticing! @abeisgoat wdyt?

[christiannaths]

Is there a reason why the emulator serves functions with /<project-id>/<region> prefixed to the path at all? I can't help but think that ~this~ doing away with these prefixes would solve not only the original bug in this issue, but alleviate the problem I'm having as well. After all, isn't the idea behind an emulator to mirror something as closely as possible? Including extra path segments runs against that grain.

But then again, I'm almost certainly missing something... 🤔

[samtstern]

@christiannaths our new emulator is replacing this one:
https://github.com/googlearchive/cloud-functions-emulator

The path was set as a convention there. It's baked into too many places to change it now without causing a lot of pain. For instance the Callable Functions SDK has this hardcoded assumption about emulated function paths.

[christiannaths]

Understood Sam, thanks for the insight. Would you accept a PR with a command line option to remove the legacy path prefixes?

[samtstern]

@christiannaths thanks for offering! We are really trying to avoid flag proliferation, and also any API changes have to go through our internal review process so let's hold off on the PR for now.

This sounds like something that could maybe be configured via firebase.json or it's also possible we could accept both paths at once. I defer to @abeisgoat

[christiannaths]

Understood.

[tmcf]

I had not tried out 69e1e1b yet and was waiting for 6.9.3

My current workaround is to set an environment variable when testing before starting the emulators

export XFIREBASE_FN_PREFIX=/[firebase-project-id]/us-central1
firebase emulators:start --only functions,hosting

In production, XFIREBASE_FN_PREFIX is not present so I default it to '/'.
This effectively lets me determine where the request handlers have been mounted and route relative to the prefix in all environments.

Cheers.

[abeisgoat]

@christiannaths Thanks for your input, this is a great question and if I'm understanding correctly, you aren't saying that the old emulator handled this well, just that the new one (with the change to match the old one) now breaks you?

If this is the case, then I think this will be a prime candidate to introduce into emulators:start so serve will have the same bug as the old emulator and emulators:start will make the prefix available in some way (along with some other IS_FIREBASE_EMULATOR type env.)

That being said, since the original issue that @tmcf reported is now fixed, @christiannaths can you open a new issue with your thoughts? Feel free to just copy/paste what you said here, I just want to keep things organized.

[liezl200]

@abeisgoat Has this been resolved? For me, emulators:start and firebase serve are still adding the path prefix and I have to use the environment variable workaround suggested in https://github.com/firebase/firebase-tools/issues/1279#issuecomment-493280145

[vmasek]

I'm experiencing this after upgrade to 7.9.0, it seems like a big breaking change for local serving as it is not mentioned anywhere and it took me several hours to figure out it isn't a bug in Angular Universal but a change in firebase tools instead.

It would be nice to mention this inconsistency with local serving somewhere as it might discourage people from deploying their functions as they do not work correctly locally.

Currently, I'm using replacing the prefix with request.baseUrl as a base should represent the prefix, but I'm not sure if it is the case in every possible scenario.

app.get('*', (req: express.Request, res: express.Response) => {

  req.originalUrl = req.originalUrl.replace(req.baseUrl, '');

  res.render('web-index', { req, res });

});

[samtstern]

@vmasek there was no intentional behavior change in 7.9.0 could you open a new issue describing the value you're seeing versus the value you expect? Thanks!