Announcing Vishnu: sessions for the Google App Engine Python Runtime

, a 5-minute piece by Brad Mclain Brad Mclain

The Google App Engine python runtime does not have native support for HTTP sessions which is a problem if you need sessions in your web application1.

Previously we had used gaesessions for App Engine projects that required session support. This worked fine and a quick code review could see no obvious flaws in its design or implementation, however, its lack of NDB support2 and no updates for over five years3 were minor causes for concern.

Another well known and widely-used option in the Python WSGI community is Beaker. Beaker is a very mature library and supports a wide array of back-ends including Google App Engine. It also had some shortcomings with no (obvious) way to configure timeouts per session and lacklustre documentation for the Google backend.

A third option was to use webapp2_extra’s sessions, however, this required the base handler to be a webapp2 one and we were looking for a WSGI middleware solution to remain compatible with many other WSGI frameworks, including our own REST framework, Prestans.

After concluding that none of the existing solutions fully met our needs we decided to roll our own.

The requirements

Based on the limitations of the existing options and given the chance to start fresh we came up with a list of requirements:

Enter Vishnu

So after choosing an awesome name plus a couple months of development and testing, we can now announce that Vishnu5 is available for public use under a liberal Apache 2.0 license.

Vishnu is a cookie-based session library for Google App Engine. It was designed to be easy to use within the App Engine environment by using the NDB datastore as the persistent backend and values located in the app.yaml file for configuration. Only one value is required (the secret) to get a session going with an additional value for encryption, making it quick and easy to get started with a secure session. All important cookie fields including Domain, Path, Secure, HttpOnly and Expires are configurable but sensible defaults are provided for all.

Security was a major concern and we made use of an HMAC signature to ensure the cookie has not been tampered with as well as the option to add AES encryption to the cookie data. Signature comparison is done using a constant time algorithm to prevent timing attacks and, by default, the cookie will be instructed to only be delivered over HTTPS, fulfilling our secure by default requirement.

Additional features include the ability to have changes made to the session be auto-saved as well as the ability to set a custom timeout value per session.

Check out the GitHub project for more details and to try it out! Feedback and feature requests welcome.


  1. Kind of stating the obvious, I know.
  2. Someone has forked the project to add support for this and a pull request has been waiting since 2013.
  3. I know, I know, no updates isn't necessarily a bad thing but can be a red flag.
  4. The hardest and most important part of every project.
  5. A major deity in the Hindu religion known as the preserver. Over a billion people are disappointed in you for not knowing this.

Next Up: a 6-minute piece by Dev Mukherjee Dev Mukherjee

Regulatory compliance in the Internet Age

Read more