Support one unified cookie with a custom name, such as __session, for Firebase hosting

[maerzhase]

Describe the bug
Serverside authentication doesn't work in firebase hosting because all cookies are being stripped but a cookie named __session is allowed. Is it possible to configure cookies so this also works in firebase hosting?

From firebase docs:

When using Firebase Hosting together with Cloud Functions or Cloud Run, cookies are generally stripped from incoming requests. This is necessary to allow for efficient CDN cache behavior. Only the specially-named __session cookie is permitted to pass through to the execution of your app.

https://firebase.google.com/docs/hosting/manage-cache#using_cookies

Version
What version of next-firebase-auth are you using?
v13.1.0

To Reproduce
Steps to reproduce the behavior:

1. Deploy examples to cloud run
2. Setup firebase hosting for your cloud run service
3. Visit firebase hosting domain
4. Try out serverside authentication

Expected behavior
Being able to use server side authentication with the cookie named __session as described in firebase documentation

[kmjennison]

Is there any way to whitelist other cookies in Firebase hosting? I didn't see one, unfortunately.

There's not currently a built-in way to set one cookie named __session, though it makes sense to support. A challenge is the underlying cookies library breaks out a second .sig cookie for signed cookies, so we'd need to combine the value and signature into one cookie. In addition, any change to cookie structure or signing needs to be backwards-compatible.

[maerzhase]

Jeah there is no way around it; and I am breaking my head around this crazy limitation given the fact that this problems exists for any service providing dynamic content through firebase hosting... 😱

As an intermediate solution what would you think of disabling cookie signing when using "unified cookie"?!

As far as I see it signing only makes sense when there is the possibility to separate the signature from the value.

[kmjennison]

I think the right approach would be for this package to always use a single cookie and allow the user to customize the cookie's full name, not just the prefix (as it does now).

See #192 (comment) for more discussion.

[kmjennison]

This might be made unnecessary if we implement #287.