Allow multiple cookies per user

[86667]

Problem

See linked ticket for explanation of problem.

Changes

• Server now generates GUID-based cookie names alongside legacy pubkey-named cookies for backward compatibility.
• Improved the authorization layer to now evaluate all valid session cookies until one with the required capabilities is found. Before it would check the first with a valid session and return 403 if its capabilities didnt match, regardless of whether other cookies in the request may have the correct capabilities.
• signout() will now remove all sessions belonging to the User
• session() will return information about the first cookie in the headers list. This is the same behaviour as before. We will consider expanding on this functionality here

Limitations

The main difference here is that multiple Cookies for a single user is now supported. This means that we need to do a trip to the db for each to verify their secrets. Ive assumed that this will not be an issue since Cookie count is generally low. We may want to think about imropving this thought, eg:

• Batch-get on DB for all sessions
• Checking a session's capabilities before fetching the next one
• Encoding a session's capabilities in the Cookie name - may have security implications?

[SHAcollision]

Looks like the test suite is failing because of clippy warnings. I anyway wonder whether it should succeed at all because as I understand create_session_and_cookie now sets the cookie path to capabilities.most_specific_scope() for both the new UUID cookie and the legacy public key cooki. For most apps that request /pub/<app>/... access, this path will look like /pub/<app>/. Browser cookie path rules mean that such a cookie will not be sent on requests to /session (or any other path outside that subtree). So I would expect that authenticated endpoints such as GET/DELETE /session can no longer see any cookies when hit from the browser, so session() and signout() will always fail with 401 right? The rust SDK keeps working because it manually injects the cookie header, but it bypasses browser semantics.

I don't know if there is any fix for this. Maybe setting path is not the best way to solve this issue to begin with. Maybe to preserve the filtering intent while keeping session endpoints working, we could attach an additional cookie scoped to /session, this one will suffer of the same bugs we've already seen in the current main codebase with chromium browsers...

[SHAcollision]

If I understand correctly, this converts every error, including database failures or internal errors, into “no sessions” and still returns 200 OK, right? The previous version returned the DB error to the client, so maybe is a regression in observability and correctness. Should propagate non-401 errors instead of unwrapping. For example, handle the unauthorized case explicitly and return Err(err) for everything else.

[86667]

I didnt want the failure of one session deletion to affect the deletion of the other sessions. Ive pushed code to awkwardly return the first error which it saw after attempting to remove all other sessions. I think this is the best we can do without introducing a regression?

[86667]

@SHAcollision The reason for setting Cookie.path to the same value as our Capability.path was to reduce the number of Cookies sent with each request, as we are now sending double the number that we were before.

If we can get away with that only by introducing another cookie for /session then it no logner provides us any efficiency gain! Reverted commit which sets Cookie.path.