Why CherryPy session does not require a secret key?

There are basically two different ways of maintaining session state: on the server or on the client.

With the server-side approach, you keep the session data in files, a database, or in memory on the server and assign an id to it. This session id is then sent to the client and usually stored in a cookie (although they can also be embedded in URLs). Then with each request, the client's session id is read and used by the web application to load the session data from wherever it's stored on the server. This way, the client never has access to any of the session data and can't tamper with it, but the downside is that you have to protect against session hijacking through the use of stale session ids by malicious clients. This is the model used by most web frameworks and applications today.

Another approach is to store the session data completely on the client side inside of cookies. The downside to this approach is that the data can be seen and tampered with by the client, so you have to take care to properly sign and encrypt the data to prevent tampering. This is where having a good secret key comes into play. The upside is that you also don't have to worry about session hijacking.

Pylons uses Beaker sessions, which can be configured to store session data completely on the client side. That's why you need a secret key.

CherryPy only stores session data on the server and then sends the user a cookie with the session id, so the client never sees the session data and can't tamper with it. You can configure it to use files or just keep everything in memory. You can even hook into it and use a database to store the session data in.

Personally, I prefer the approach used by CherryPy, since it's the same approach used by the majority of the web. It's easier to secure, and you can easily share session data with other applications running on your server without worrying about encryption or keys.

Recommended topics

Hot tags