On Encrypted Cookie Sessions

June 16, 2011 § 1 Comment

Once I had finished up with the encrypted-cookie gem, it seemed like a natural extension to convert it into a Rails 3 session store.  It operates just like the basic cookie session store, just using an encrypted cookie instead of a signed cookie.  It uses the encrypted-cookie gem, so all the encryption is provided by ActiveSupport::MessageEncryptor.  To start using it add the following to your Gemfile:

gem 'encrypted-cookie-store'

And change your session store in config/initializers/session_store.rb

AppName::Application.config.session_store :encrypted_cookie_store, :key => '_app_name_session'

The dependencies will include the encrypted-cookie gem for you.  Accessing the session is the same as always:

session[:tid_bit] = "of information"
session[:tid_bit] # => "of information"

You can check out the source over on github.

Currently this only works with Rails 3.0.*. All of the session code got switched up for Rails 3.1, so it’s going to take some extra work to get it working for the new release of Rails. Update June 18: Got it working with Rails 3.1.  Yay conditional method definitions!!! Sigh…

Advertisements

On Encrypted Cookies

June 16, 2011 § 2 Comments

I love cookies.  Well, despite obviously loving the cookies of the baked goods variety, I also love Rails 3 cookies. I know it’s weird, but if you are looking for things that aren’t weird, you probably are in the wrong place. The specific thing I really like about the Rails 3 cookie system is that it is chainable.  So cool.

They are three types of built-in cookies.  Your basic everyday cookie, a permanent cookie and a signed cookie.  The basic cookie just saves something to a cookie in the user’s browser.  You can add an expiration date if you’d like.  The permanent cookie sets the expiration date 20 years from now and the signed cookie cryptographically signs the contents of the cookie so that people can’t tamper with it.  The way you interact with them is slick.

cookies[:things] = "stuff" # assign
cookies[:things] # read
cookies.permanent[:perm] = "Never going away" # write to a permanent cookie
cookies[:perm] # read a permanent cookie
cookies.signed[:tamper_proof] = "fragile info" # write to a signed cookie
cookies.signed[:tamper_proof] # read a signed cookie
cookies.permanent.signed[:perm_tamper_proof] = # write to a permanent signed cookie
cookies.signed[:perm_tamper_proof] # read the permanent signed cookie

Now it is best practice to not put highly sensitive information in cookies. There is just no telling what is going on with a user’s browser and their computer.  But there are times where you might have some pseudo-sensitive info that you want to store in a cookie.  Not things like social security number, but maybe some app info that you would rather people not see, but it wouldn’t be the end of the world if they did.

Enter encrypted-cookies.

encrytped-cookies is a ruby gem that provides access to encrypted cookies for Rails 3 apps.  It’s built to work exactly like signed cookies, so there isn’t really anything else to say about the usage except to show the two line example:

cookies.encrypted[:secret_cookie] = "nothing to see here" # write to a signed cookie
cookies.encrypted[:secret_cookie] # read a signed cookie

Piece of cake.

I should probably mention how I do the encryption, since that is something you are probably curious about. The great thing about is that I don’t do the encryption!  ActiveSupport has this nifty little module called ActiveSupport::MessageEncryptor.  It does exactly what you think it does.  It encrypts and decrypts messages.  I didn’t want to take a chance writing the encryption code myself.  Waaaaay to many places to make a mistake and really screw over someone using this gem.  The signed cookies in Rails 3 use ActiveSupport::MessageVerifier to make sure the cookie payload hasn’t been messed with.  In reality, encrypted-cookies does little more than swap out verifier code with the encryptor code.  But simple code has fewer places for bugs to pop up.

Happy encrypting.

On Serialized Accessors

June 16, 2011 § 1 Comment

One of the nice things about brand new Rails apps is that all of your database tables are nice, small and manageable.  You have relatively few columns in any given table and you are probably querying on most of the columns at some point in the app.  As your app grows in size and complexity, so do your tables.  A table that once upon a time had 5 or 10 columns now has 20 or 30.  Not unreasonable number, but you are starting accumulate a number of columns that aren’t queried against.  What should we do with these columns?

One option is to just let them build up.  It doesn’t really hurt anything does it?  I am sure that some database experts out there can weigh in on how number of columns affects performance.  Option two is where I’d to show off something a little more interesting.  Check out the data-attributes ruby gem over on github.

The premise is pretty simple.  ActiveRecord allows for easy serialization of objects to a text field in the database. data-attributes makes use of this and adds attributes that read from and written to a serialized hash that is stored in a text field in the database. From the developers perspective, once a data attribute is defined, it can be used just like any other attribute. Validations work just like they do on column based attributes. To use this gem just add the following to your Gemfile in your Rails 3 project.

gem 'data-attributes'

Let’s take a look at it in action.  We start with a user model with a serialized attribute called data.

class User < ActiveRecord::Base
  serialize :data
end

Now, let’s say we have some piece of information that we want to include in the user record, but it isn’t something that we are going to have every query on.  We define a data attribute like so:

data_attribute :favorite_food

Now how do we use this?  We can see the results of adding the above to our Userobject.

u = User.new
u.favorite_food = "watermelon"
puts u.favorite_food
=> watermelon
puts u.data.inspect
=> { "favorite_food" => "watermelon" }

Pretty easy.  The default field that the gem tries to save everything to is data, but that is just based on personal convention.  If you want to change this, it’s as easy as adding the following line to your model:

data_attribute_column :food_preferences

Or if you have multiple serialized attributes and you want to send different data attributes to different serialized attributes you can do the following:

data_attribute :favorite_food, { :serialized_column => :food_preferences }

You can also set the default value to be returned for the data attribute:

data_attribute :favorite_food, { :default => "peanut butter" }

One of the things that makes all of this possible is that fact that ActiveRecord has multiple layers of accessor that happen when you call something like user.name.  What happens is that the method name gets called which in turns calls read_attribute(:name).  Similarly name=(val) calls write_attribute(:name, val).

data-attributes contains similar under-the-hood method read_data_attribute and write_data_attribute.  This way you can have a little more control over the values that are read and written to your object.

Some things to be noted. If your ActiveRecord object has a serialized attribute then that attribute will be saved to database every time you call save.  This is because it doesn’t know if the serialized object has been edited in place or not, so it just writes it to the database every time for good measure.

Update 2011-12-26: ActiveRecord 3.2 now has some of this basic functionality built in by way of ActiveRecord::Store.

Where Am I?

You are currently browsing the Gems category at The On Blog.

%d bloggers like this: