WIP: add session middleware with pluggable backing

[chrisdickinson]

WIP: Add pluggable session middleware

Per #9 – I had some rough session middleware I was working on in support of building a blog in Tide. It's patterned off other session middleware I've worked with in the past (e.g., in Django) & is similar to what powers www.npmjs.com.

Including this middleware in an application gives handlers the ability to access and modify a long-lived session object via a SessionExt trait:

    app.at("/").get(async move |ctx: Context<()>| {
        // SessionMap implements Deref<HashMap<String, String>>
        // If this happens during a request a session will be created and
        // a session id sent to the user in a cookie.
        sess.insert(String::from("username"), String::from("chris"));

        // Or: rotate the session without making any changes
        let mut sess = ctx.session_mut();
        SessionMap::rotate(&mut sess);

        "Hello, world!"
    });

    app.at("/ronly").get(async move |ctx: Context<()>| {
        // or fetch the session in a read-only way, guaranteed to not create new sessions
        let sess = ctx.session();

        "Hello, world!"
    });

Users are able to provide their own backing store:

struct InMemorySessionStore;

impl SessionStore for InMemorySessionStore {
    fn load_session(&self, key: &str) -> SessionMap {
        SessionMap::new()
    }

    fn commit(&self, key: Option<&str>, session: Ref<Box<SessionMap>>) -> Result<HeaderValue, std::io::Error> {
        Ok(HeaderValue::from_static("<a cryptographically secure session token>"))
    }
}

(Tide would ideally provide a memory store & possibly a redis- or memcache-backed store?)

Motivation and Context

I am coming from Node, where (until recently!) I used to work on the npm registry & website. At my new day job, we're moving from Node to Go, and I'm trying to get a feel for how Tide and Rust might fit into that same space. Also – I have the cycles to contribute back to open source now, and I'd really like to invest as much of that time as possible back into Rust!

As a result, I picked the goal of building a blog + management system for my personal site. One of my requirements is that I be able to log in to manage posts, so I needed session middleware.

This is a draft PR to start a conversation about how to accomplish that task: I'm happy to continue working on it, pair with someone else, go back to the drawing board entirely, or buzz off for now if this takes more cycles from maintainers than it returns! (Y'all have been doing great work 💞)

How Has This Been Tested?

This has been manually tested in a local application. I'm planning on patterning the tests after the other middleware in this repo.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[yoshuawuyts]

@chrisdickinson thanks so much for starting work on this! -- The general direction here seems very promising -- also the conversation in #9 seems great.

Regarding this implementation, probably the only comment I'd make is that I'd expect the load_session and commit trait functions to be async. If they're making requests to external databases we'd likely not want to block while the results are being fetched.

However async fn in traits is currently not supported yet. So in order to make these work asynchronously, workarounds would need to be applied which are similar to http_service::HttpService. (Which is to say: define associated Future types).

Very excited for this!

[yoshuawuyts]

Published https://crates.io/crates/async-session which is a continuation of the work done in this patch. Next step would be to build a middleware that can use that to integrate with Tide.

Going to go ahead and close this PR for now. Thanks so much @chrisdickinson!