Storing cookie value + signature in a unified cookie instead of cookie_name.sig

[maerzhase]

So I am building an app in this "awesome" eco-system called firebase—it comes with the "beautiful" convention of stripping all cookies out and leaving you with the ability to use only one single cookie called __session.

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

Since I'd like to keep the possibility to sign this __session cookie, I was wondering if it's worth to build a solution where the signature is actually stored within the cookie rather than an cookie_name.sig BUT i am not sure if this is a valid approach.
I am wondering: Does a signature still make sense if its stored within the same cookie? Or does it defeat the signing purpose? I would be super thankfull if someone could shed some light on this!

If this is a valid approach and you are interested to add this feature to the lib—I'd be keen to provide a solution to this scenario.

[noinkling]

The reasoning for using a separate cookie seems to be in the readme:

This allows other libraries to access the original cookies without having to know the signing mechanism.

Though that benefit seems kind of dubious to me. It also means the implementation doesn't need to strip the signature from the value before verifying it. I know there are other libraries/frameworks that use a single cookie though.

This is likely far too late at this point to help @maerzhase, but for reference, if you only want a single cookie for whatever reason, you could use a JWT which has it's own built-in signing mechanism (and of course takes care of serialization and encoding too).