joerussbowman / AsyncMongo-Sessions

A sessions library for Tornado using AsyncMongo
30 stars 2 forks source link

AsyncmongoSession class, used to manage persistence across multiple requests. Uses a mongodb backend and Cookies. This library is designed for use with Tornado.

Built on top of asyncmongo by bit.ly - https://github.com/bitly/asyncmongo The decorator is written to be completely asynchronous and not block.

There are also some built in security features for the session. Only a token is stored as a cookie, all data is stored in MongoDB. The token rotates on a schedule you can define, the default is a token is valid for 5 seconds, with the 3 most recent tokens being considered valid. This helps lessen the risks associated with session fixation for non-ssl connections. Because of this the library will be more write heavy than standard session implementations.

The session is added as session property to your request handler, ie: self.session. It can be manipulated as your would any dictionary object.

Included with the library is a settings file, configured for default permissions. Some of the more advanced tuning you can do is with token expiration. In order to create some additional security for sessions used in a non-ssl environment, the token stored in the browser rotates. If you are using ssl, or more interested in performance than security you can set SESSION_TOKEN_TTL to an extremely high number to avoid writes.

Note: In an effort increate performance, all writes are delayed until after the request method has completed.

Example: @tornado.web.asynchronous @asyncmongosession def get(self): if self.session.has_key("test"): self.session["test"] += 1 else: self.session["test"] = 0 self.render("index.html", session=self.session)

IMPORTANT: If using the asynchronous wrapper from Tornado you must wrap the asyncmongosession with it, not the other way around. Otherwise it will error and not render because the request finish method will be called multiple times.

TODO: Support signed cookie data as session data. In instances where the session data doesn't need to be protected, such as anonymous users, it would be beneficial to not have any read/write processes happening to the database.