Rocket: Sessions?

[fivethousand]

Are there any plans to add session support or is this something that should be handled completely externally?

On the one hand it would create a dependency to some storage provider, which should be up to the user (-> contrib?), but on the other the integration could be very elegant and many applications require it.

[impowski]

Think Sergio already working on it.

[Eijebong]

Have a look at #20 and #96

[fivethousand]

I've seen #20, but that didn't answer my question (one could just get the session id cookie and still have to provide a storage yourself).

What I don't understand though is why searching for "session" didn't show #96.

Thanks!

Edit: My bad... #96 is closed, and I restricted the search to open issues only. Meh.

[SergioBenitez]

There are two things people are generally referring to when they use the word "sessions" in the context of web applications:

1. Cookie-backed sessions.

   These sessions are maintained by the client's machine via cookies. These session cookies contain the full session data. They are encrypted and signed, providing for cryptographic confidentiality, integrity, and authenticity.

2. Database/store-backed sessions.

   These sessions are maintained mostly server-side, usually in an in-memory database. A cookie is used to identify a client with the corresponding server-side session, but no additional information is stored in the cookie.

I am actively working on 1. I should have a working version of these types of sessions within a week. They will be available as part of Rocket 0.3.

Rocket core is highly unlikely to contain an implementation of 2. The main issue is that it requires a database of some sort, a rather large dependency. Something like this _might_ be good for contrib, but in all likelihood, it's likely better as its own external crate with the appropriate implementations for easy use with Rocket.

[fivethousand]

Thanks for the clarification!
I was initially exclusively considering option 2, but thinking again I guess option 1 is good enough.

[mehcode]

@SergioBenitez I want to agree. My only argument is that if I (or someone else) were to spend time writing a generic session crate (and make it work nicely with Rocket) it would likely include both option 1 and 2.

Would you be amiable to the bulk of the session work being in an external library and just the rocket glue here?

I'm thinking of something similar to python's Beaker library.

See https://beaker.readthedocs.io/en/latest/

[SergioBenitez]

@mehcode It seems okay if some external library includes support for 1 and 2. What concern do you have if this would be the case? The bulk of the session work is already external via an upstream contribution to the cookie crate (https://github.com/alexcrichton/cookie-rs/pull/76).

[SergioBenitez]

Closing this in favor of #20 in light of the latest discussion.

[liufuyang]

@SergioBenitez Hey Sergio, thank you for creating this Rocket frame work. Currently I am having lots of fun with it.

Just another question about session. As you mentioned above there are 2 ways. I can see method 1 is working now. However, is it simple to do method 2 in a memory based storage?

In my use case, after user logs in, I would like to store some other secretes associated with this user on the server side in memory. So whenever the user logs in again, he can uses these secretes for other stuff.

Do we already have this feature in Rocket 0.3 or can it be simply implemented by some customer code? (I am not a master on Rust concurrency yet :P ) I would nice if there are some code example showing this.

Or, do you recommend to try save everything on the client cookie side?