Session management

[aturon]

Work out a good story for session management in Tide. No need to reinvent the wheel here: this can probably follow an approach taken by an existing framework, like actix-web.

[skade]

Ideally, I'd prefer all the algorithmic parts of session handling (and strategies) implemented as libraries somewhere.

[aturon]

Definitely! The whole idea with Tide is to keep as much in the library ecosystem as possible. In some cases we're starting with code here for convenience and then moving it out.

I'm not sure what's currently available in the ecosystem here that's not tied to an existing framework. If we need new general purpose crates, can add to the rust-net-web org.

[bIgBV]

I wen through the following frameworks when understanding how they track state for a request during its lifecycle.

• Rocket
• Actix-web
• Tower-web

I'm typing out what I learned about the different implementations with a recommendation of how to proceed with the same in Tide at the end.

Rocket

Rocket only seems to support storing state in a request through the Cookie type. I think it is because they use a custom Request type. The cookies themselves are per request and are stored in a RefCell (though I'm not entirely sure why).

This approach seems a little inflexible as there is no state store across requests on the server side of things. You have to store information as a private cookie and retrieve it every time in order to persist state across requests.

Tower-web

Tower web doesn't seem to have a user facing API for storing cookies or any kind of session for a given request. It does have a AnyMap for storing app wide config.

I think since tower-web is still under development, the API ins't decided yet.

Actix-web

Out of the three, actix-web seems to have the most complete session storage implementation. It has a generic Session which provides the interface the session storage. The backend for this storage could be anything that implements the SessionBackend trait. The interface for accessing data from the backend is through the SessionImpl trait. By default, the SessionBackend trait this is implemented for the CookieSessionBackend, which wraps over the CookieSession type which implements the SessionImpl trait. This is built on top of the cookie crate.

This is definitely the most flexible and complete solution out of the three frameworks I've looked into.

Conclusion

While Rocket provides a straightforward way to get started with store state for a request, the implementation provided by actix-web is definitely more feature complete. I think we should definitely take inspiration from this when we consider session storage in tide. Since there can be different session backends, this could provide a great way to integrate into the authentication and authorization API by interfacing with the generic SessionBackend type.

I did not do an extremely deep dive into these frameworks, so if I missed something, please feel free to let me know 😄

[tomhoule]

I just published a rough prototype of what it could look like: https://github.com/tomhoule/tide-cookie-session - it's closest to the actix_web design, with pluggable session storage. I would love if some of you had feedback on it :)

[bIgBV]

@tomhoule that is a really cool implementation. I was planning on writing something very similar to what you've written. So a couple of things come to mind.

Right now the API around extractors might be changing, so that's something you might want to keep an eye out for. I think it's best to think about including this into tide itself once that's in place. That way, we could also use the app wide config to store the in memory session store instead of extracting it from the request object. I can see both pros and cons for this approach.

I think it'd be better to separate the storage, session and middleware types form their implementations. Just a thought, since it took me a little while to understand what's going on (though you could attribute that to my inexperience in Rust 😅)

I really like the design and feel it's really flexible and I'd love to try and write a simple redis storage, just to get a hang of how it works. Is it okay if I fork your repo and send a PR across once I have something running?

[tomhoule]

Thanks for the feedback! I put the session storage in the middleware because it seemed the easiest to implement, but you are right that we could put it in application state and it might be better, I'll try to see how that would be done.

And yes it's probably hard to read, I'll try to put some order and write minimal documentation today to make it easier for others to evaluate it.

[bIgBV]

@tomhoule just saw your changes, these are awesome. I think we can move this into tide, and start working on integrating Storage and Session types into tide itself, and then have the CookieSessionMiddleware middleware as a part of the middleware module.

That's my idea at least and I might be missing something. @aturon @yoshuawuyts , do you guys want to pitch in?

[yoshuawuyts]

@tomhoule thanks for making this! The API looks like a cool basis to build on further!

I think we can move this into tide, and start working on integrating Storage and Session types into tide itself, and then have the CookieSessionMiddleware middleware as a part of the middleware module.

@bIgBV I think that would be a great next step!

[bIgBV]

@yoshuawuyts aren't the changes from #126 going to affect the changes made by @tomhoule ?

[yoshuawuyts]

@bIgBV ah yes, that's fair. We should make a decision on how to proceed.

[bIgBV]

@yoshuawuyts after going through today's meeting notes, I think its better to wait for aturon's proposal and the changes around that before going ahead with this.

[tomhoule]

I just read yesterday's meeting on Discord, and the proposed new design looks great. I'll update the crate to fit it when it lands.