Dynamic session key prefixes about async-redis-session HOT 3 OPEN

// 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!

from async-redis-session.

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)

from async-redis-session.

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.

from async-redis-session.