Dynamic session key prefixes

[mdtusz]

A very useful benefit of using sessions rather than JWT's for auth is the ability to invalidate all existing sessions for a user. This currently requires storing the session ID's used for each session in a table or somewhere so that they can be looked up in the future. In a similar vein to providing a static key prefix, a dynamic prefix computed using the session itself (and optionally the provided static prefix string) would allow for using keys like user_session:<USER_ID>:<SESSION_ID>. While this may be a niche use case, it would allow for more granular session management and most importantly for my use case, invalidating all existing sessions for a given key prefix.

I'm happy to do the implementation of this, but am putting the idea out for feedback and input on whether it fits with the crate design and goals!

[mdtusz]

// User defined function that creates the key string to be used when inserting to redis. 
// It is up to the user to ensure that the returned key string is consistent and will remain
// consistent for a given session.
fn make_key(key: impl AsRef<str>, prefix: Option<String>, session: Session) -> String {
   let pre = prefix.unwrap_or("");
   let user_id = session.get("user_id").unwrap_or("anonymous");
   
   format!("{}{}:{}", pre, user_id, key)
}

let session_store = RedisSessionStore::from_client(redis_client)
    .with_prefix("foo:")
    .with_prefix_fn(make_key);

I was thinking an interface that looks something like this could work, and as far as I can tell, this wouldn't break any backwards compatibility. Naming is hard, so suggestions for something better than with_prefix_fn are welcomed!

[jbr]

When we're looking up the session on subsequent pageloads, how would we know the user id? I'm not opposed to this idea in the abstract, but I'm not clear on exactly how it would work. I think granular session management might require storing additional data in redis from application code (a lookup table from user id to session id)

[mdtusz]

Ah yeah total brainfart on my part that the session data isn't present when loading it 😆. It would ideally require storing an encoded value in the cookie itself (which maybe is an option?), but the other option is to allow the user to specify the key for retrieval separately as well so that the computed "store" key could be something like user_session:<user_id>:<cookie_value> and the corresponding "load" key could be user_session:*:<cookie_value>. This is a bit tricky since you can't use the redis GET command with wildcards and would need to use KEYS followed by GET using the returned key result, and because of that would require using either two requests to the redis server, or using a combined lua script execution to do it in one which gets messy.

The alternative I suppose is to just manually query for KEYS user_session:* then retrieve using GET <one_of_the_returned_keys> and filter for the desired user_id (or whatever other session data). The only downside to this is that you have to deal with and filter through a (potentially) large number of sessions, and if there's a large amount of data stored in the session, this could become problematic. I'm trying to avoid creating a table in our main oltp db just for this, but it may be the best route.