Sessions middleware

[dranikpg]

Sessions

In modern web frameworks almost all other parts rely on some kind of session management. Crow currenlty has no way of doing this easily and uniformly. I'd suggest to start with sessions, as they can lay the fundation for all other sorts of middlewares and utilities.

This allows to further work on #363 and solves #144

Goal

A session is a temporary key-value storage associated with some client. It mainly stores small short-lived data: is the user authenticated, what page did he visit last, did he click on your new advertisment.

Our neighbour flask-sessions provides access to a simple dict and allows to choose one of many storage backends (encrypted in cookies, in-memory, filesystem, redis, database).

Conveniently integrating different storage providers is a bit tricky. They can be divided into two groups:

• providers that take full responsibility for storing and managing all data (like cookie-only storage)
• providers that require only an id (redis/database/filesystem storage). They should be able to rely on Crow for storing this id in cookies. (like JSESSION in Spring)

First off issues

Cookie parser

The current cookie parser is limited. It doesn't allow to set any settings (expiration, max-age, doman, path...).

Middleware dependencies

I'd be great if middleware could list its requirements, so that we could clearly tell that Sessions (if used with cookies) depends on the cookie parser and that it has to be listed before the sessions middleware.

Further planning

The first group requires only a request/response for managing data. It can, for example, read headers (for tokens) or pull out the cookie parser from the request.

// load data from a request
map<string, string> load(const request&)
// store data in a response
void store(response&, const map<string, string>&)
// providing a list of changed keys would allow to send only new cookies
void store(response&, const map<string, string>&, const vector<string>&)

We could simplify development by having a different interface for the second group. However I'm not sure whether it's worth it. Automatic cookie management saves only a few lines, but makes the interface a lot cleaner. Why should an in-memory storage care about how to extract cookies?

// generate a new key
string generate()
// set cookie settings (name, expiration, ...)
Cookie cookie()
// load data by a key
map<string, string> load(const string& key)
// store by a key
void store(const string key&, const map<string, string>&)
// likewise providing a change-list would be more efficient

Roadmap

• Improve cookier_parser, add middleware checks
• Implement sessions middleware
• Implement some basic storage backends (all-in-cookies, in-memory, files)
• Use it as one of authentication backends (bare http-auth is rarely used, often managed by cookies/tokens). Besides, it takes just few efforts to implement your own security system over sessions now that Blueprint middleware #403 is on its way

Any comments on the roadmap? Is it en par with your visions? Maybe we should change/reshape something?

[The-EDev]

Everything seems okay but I'm not sure I understand this one bit:

Automatic cookie management saves only a few lines, but makes the interface a lot cleaner. Why should an in-memory storage care about how to extract cookies?

The first bit doesn't seem to have a downside, saves lines and cleans interface. And the second bit is missing context I think.. is it something like "Automatic cookie management saves lines, and makes the interface cleaner, but it doesn't make sense to have it in there". In that case I would go with whichever solution is clearest/simplest from the framework user's perspective.