This module exports tools for safely storing encrypted data on client-side cookies through Network.Wai.

This module is designed to be imported as follows:

import qualified Wai.CryptoCookie

One example of how to obtain a new Network.Wai.Middleware,

do (middleware, lookup) <- do
      key <- Wai.CryptoCookie.autoKeyFileBase16 "/run/my-cookie-encryption-key"
      Wai.CryptoCookie.middleware (Wai.CryptoCookie.defaultConfig key)

The obtained middleware shall be applied to your Network.Wai.Application.

The obtained lookup function can be used to obtain the CryptoCookie associated with each Request. It returns Nothing if this particular middleware was not used on the given Request.

Finally, interact with the CryptoCookie data using get or set.

Do I store session data on the client or on the server?

It's not so much about where to store the session data, but about how to store it and how to expire it. Here are some ideas. But please, do your own research.

1. Data on server, identifier on both: In this approach, all the data is stored on the server. On the CryptoCookie, simply set a unique session identifier and later get it back and use it to find the associated session data on your server-side database. In order to expire the session, all the server have to do is remove this session identifier from its database. Choose this option unless you know what you are doing, it doesn't require you to plan ahead too much.
2. Data on the client, identifier on both: In this approach, all the data and session identifier is stored on the CryptoCookie. On your server-side database, store the session identifier and a timestamp representing its creation time or last session activity time. Before accepting the session data from the CryptoCookie as valid, check that the session identifier exists in your database, and that the time since the timestamp is acceptable. This approach is simpler on your server-side database, but it can lead to more network traffic, and schema migrations for session data will be complex if you care about backwards compatibility with currently active sessions.
3. Everything on the client: You can store everything in the CryptoCookie. However, you will be more suceptible to replay attacks because you won't have control over session expiration beyond comparing the current time against the session creation timestamp or last activity timestamp previously set in the session data. You can force all the existing sessions to “expire” by rotating your encryption Key. Also, this approach can lead to more network traffic, and schema migrations for session data will be complex if you care about backwards compatibility with currently active sessions.