pmalmsten / cosmosdb-extensions-sessiontokens-aspnet Goto Github PK

Cosmos DB only changes session token values on writes. Furthermore, the current version of this code saves the session token for any response from Cosmos DB, whether it is a read or a write. Given that, there is a possible data race where a concurrent read that finishes after a concurrent write could overwrite the current session token for the current request context with an old session token value.

Example scenario:

1. App starts with current session token A
2. App starts async write request (without awaiting)
3. App starts async read request (without awaiting)
4. App awaits both requests.
5. Async write request completes, current session token for the request context is set to B
6. Async read request completes, current session token for the request is set to A (overwriting the value of B)

Preferred behavior:
When the async read request completes (step 6), it should not overwrite the session token value saved from the write in step 5.

Cosmos DB session tokens may expire. If a client calls the app and receives a session token (e.g. in a cookie), and then waits an extended period before calling the app/API again, the session token may have expired.

The Cosmos DB SDK throws an exception when a session token is invalid - it most likely does the same when a session token has expired. What that occurs, the container interceptor should not application code to fail.

Instead, the container interceptor should most likely retry the request once without setting a session token on the request, so that Cosmos DB can issue a new session token which we can include as the new value for the cookie on the response.

To minimize the total size of generated HTTP headers, the combination of account URI, database name, and container name are hashed, and the resulting hash is truncated to a shorter integer (currently between 0 and 1,000,000).

The probability of collisions is relatively low, but the possibility of it happening is may be non-trivial when large numbers of containers are involved (e.g. 50 containers).

We should do the right thing if/when that happens. To start brainstorming, this might include some combination of:

• If running in a development environment, throw an exception - otherwise, log an error and drop the conflicting session information
• Provide a way for users to override the automatic code assignment behavior for specific account/database/container combinations, in order to work around conflicts when they are discovered
• Or, as an alternative to the other workarounds, increase the set of possible container codes until collisions are sufficiently unlikely to be ignored entirely. (Not a particularly attractive choice, since this would mean silent problems for users, and would increase the size of HTTP headers for everyone using cookies).

According to the Cosmos DB REST API documentation, session tokens are scoped per collection: https://learn.microsoft.com/en-us/rest/api/cosmos-db/common-cosmosdb-rest-response-headers

At present, session token cookies set by this middleware only include database name - they do not include account name, or collection name.

We need to ensure that session token cookies 1) are separate for databases in different cosmos DB accounts, and 2) are separate for different collections (aka. containers) in a single account.