jbr / async-redis-session Goto Github PK

Thank you for putting together this extension of the async-redis package.

The redis dependency uses the features = ["aio", "async-std-comp"].

Does that mean I can't use a client that uses tokio: redis = { ... features = ["tokio-native-tls-comp"] }?

Hi, how is can you set the redis store as a layer or service in the main function so the connection can be used in handlers?

First of all, thanks for this crate! This and async-session have been really useful in setting up the project I'm working on.

I have a feature request, though; I want to be able to check the current connection to Redis to make sure it is still working, for a healthcheck endpoint. I believe I can do that by just calling .get_connection() on the redis client, but that is a private field in RedisSessionStore so it needs to be implemented on there.

I can just add a trait to do this and hack around it, but I thought it'd be better to add to the actual crate for others to use. I'm going to make a PR to add this feature, just thought I should make an issue first to explain my reasoning.

Hi there, I'm hoping to check in and see where we're at with maintaining this crate. If there's interest, I'd be happy to help pitch in here.

I'm using published latest version (0.2.2) of this crate in my project. It shows warning when I build my project. From message, This is because this crate (0.2.2) depends on redis ^0.20.1. Latest version of redis (v0.23.0) seems to resolve this issue. Could you update redis version and release new version of this crate to clear warning message?

$ cargo -V
cargo 1.68.2 (6feb7c9cf 2023-03-26)
$ cargo check
    Finished dev [unoptimized + debuginfo] target(s) in 0.22s
warning: the following packages contain code that will be rejected by a future version of Rust: redis v0.20.2
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 53`

let session_store = RedisSessionStore::from_client(redis_client);

I've updated redis-rs's version to the latest and all tests have passed.

Hello,
sliding expiration need to reset the time to live in session after each request.
i am sorry, i see ttl_for_session method, it is great!

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!

It seems this no longer works with Tide 0.16.0. I'm seeing this error:

the trait `Middleware<()>` is not implemented for `SessionMiddleware<RedisSessionStore>`