ruby on rails, jruby, aws, ec2, exalead

It is one of life’s strange coincidences that in the week where Rack middleware was brought firmly into the spotlight in Railsland thanks to the introduction of Metal and the continuing transition of Rails to a Rack application that I finally had a need to write some middleware of my own. Up until now I’ve had a rough understanding of how Rack works and how middleware can used to provide customised processing in a web request but I haven’t actually needed to use it for anything.

When the default session store for Rails was changed to use cookies last year it caused quite a furore: "It’s not secret! It’s not safe!" The truth is it was never meant to be: in most circumstances you shouldn’t really be storing data in cookies that need to be protected so strongly. But I don’t really want to re-open that can of worms! Instead I want to look at a different cookie-related situation that arose during some optimisation work I’ve been doing on an existing Rails application.

The scenario is straightforward enough: the application stores a numeric record ID in a persistent cookie that, while perfectly safe to be seen by users, shouldn’t be changed by them. The solution currently used in the application is equally straightforward: the data is encrypted (using the EzCryto gem and AES encryption) before being written to the cookie, and then decrypted when the data is read back in.

In situations where cookie contents really shouldn’t be seen by users then encryption is the way to go (unless of course you can find a way of not using a cookie at all), however for a simple numeric ID where tampering is the only thing we need to protect against then it seems like overkill. A better solution is to take inspiration from the Rails cookie session store and use a HMAC.