CODEWITHSUNDEEP
firebasecookiesgoogle-cloud-functions
John
John

Reputation: 10049

Firebase https function unexpectedly strips `set-cookie` header

As (indirectly) mentioned in the firebase functions docs, https functions are suppose to support manipulating cookies in request / response headers.

If you need to inject middleware dependencies for things like cookie support or CORS, call these within the function.

However, the following HTTPS function returns a response which does not contain a set-cookie header to the client:

functions.https.onRequest(async (request, response) => {
  response.set('access-control-allow-origin', '*');

  response.cookie('TEST COOKIE', 'Success!!!!');

  console.log(response.get('set-cookie'));

  response.json({ status: 'success' });
});

Strangely, the call to console.log(response.get('set-cookie')) shows me that the set-cookie header is set at that point in the function call. So somehow the set-cookie header is being stripped from the response. This certainly seems like firebase functions don't actually support manipulating cookies.

Does anyone have any idea what's going on? I've been trying to figure this out for hours now :(

Upvotes: 2

Views: 2060

Answers (1)

John
John

Reputation: 10049

Oh my goodness I figured it out! The firebase function is setting the "set-cookie" header normally. The issue is twofold:

  1. The domain associated with the firebase function is a google domain. You can't set functions for other domains (this is a browser restriction), so a hosted function cannot set a cookie for localhost. It also can't set a cookie for your app domain (which will be different than the domain associated with the function). You'll need to alias the function under your own domain for the ability to set cookies for your own domain (this won't help in development though). See this issue: https://stackoverflow.com/a/51461847/5490505.

  2. This one really annoys me, Google Chrome (v71) automatically hides the "set-cookie" header from the response if its being sent by another domain. If you were attempting to set the cookie for the app's domain, in this case the cookie wouldn't be set anyway, because of browser restrictions. If you don't specify the domain of the cookie however, then the cookie is set for the domain associated with the function, but Google Chrome doesn't show you the header and you have no idea it was set unless you examine your browser's saved cookies. This also gives the appearance that the header isn't even being included in the response, when it is. I thought that the cloud function was stripping the "set-cookie" header, when in fact Google Chrome was stripping the "set-cookie" header. I really don't like this design decision. It made debugging SO hard and I wasted so many more hours on this problem. Firefox behaves as expected, showing you the "set-cookie" header.

I'll also note that, for my purposes, the firebase function is setting a secure, httponly, cookie that is only read by other functions. In this case, having the domain of the cookie be the domain associated with the functions is totally fine (my client side app never looks at the cookie anyway). As such, even though Chrome doesn't show the "set-cookie" header, the cookie is being set and everything is working fine. Another reason why Chrome's design decision is so, so bad.

Upvotes: 7

Related Questions