How Ruby on Rails Session secret is generated or stored

Ruby on Rails's default session store is cookies, and it has all the info encoded in Base 64. So anybody can look at the info by Base64 decode. Note that often, even the user id of the logged in user is in the cookie, and the authenticated system installed or implemented on Rails will assume that this is the valid user id of the logged in user and fetch all data / settings, allow permission according to this user id. So how can Rails prevent somebody from faking to be another user?

It is by verifying the cookie data by encrypting with a secret key. Then the result is compared to the checksum tagged along in the session cookie. (The session cookie has 2 parts: the data, and the checksum).

When a Rails application is created, the secret key is automatically generated for you. So even if you don't specify a secret key, don't worry, one is already there:

Rails 2.2.2:

in config/environment.rb

# Your secret key for verifying cookie session data integrity.

# If you change this key, all old sessions will become invalid!

# Make sure the secret is at least 30 characters and all random,

# no regular words or you'll be exposed to dictionary attacks.

config.action_controller.session = {

:session_key => '_foobar_session',

:secret => '0d7d7d5ec0680cfd1d716bba057bce35a92a920a4471aa274ef0224ee52ebaa9eae43952418f7954fdef49b63d5b8eacc6efecf4bc2a29c45e8625a07f820e48'

}

Rails 2.3.8

in config/initializers/session_store.rb




# Your secret key for verifying cookie session data integrity.

# If you change this key, all old sessions will become invalid!

# Make sure the secret is at least 30 characters and all random,

# no regular words or you'll be exposed to dictionary attacks.

ActionController::Base.session = {

:key => '_foobar_session',

:secret => '81c3c1e81b899ea2cff8d9321a67df7c88978ad985a4b39118d2061f2f8b946392575cdff2e5e7cd83eb0493ba200eb07c51d11cd191a681dbdb19673f2d0da7'

}

Rails 3.0.4

in config/initializers/secret_token.rb




# Your secret key for verifying the integrity of signed cookies.

# If you change this key, all old signed cookies will become invalid!

# Make sure the secret is at least 30 characters and all random,

# no regular words or you'll be exposed to dictionary attacks.

Foobar::Application.config.secret_token = 'ce90ddf2fb13e290e077fc8a3ac865a52fde53595fe905af032fd07301a1715c2f6efd28c285c3543cbd45b27107fb95ed7d6778c28cc1225c1157e0fa69bf25'

Ruby on Rails Restful Authentication - How it works

This is an overview of how Restful Authentication works. Restful Authentication a Ruby on Rails plugin. You install it, and the code is in

vendor/plugins/restful_authentication

if your directory is restful-authentication (a hyphen instead of an underscore, then you probably want to rename it to using an underscore, because as stated in the GitHub, there is an issue if it is not.

A method of major importance is

current_user

Note that it looks like a variable, but it is actually a method. It returns the current logged in user. Note that it is actually a User object, so you can use the fields in the users table in the database as you wish. So for example, if your Rails application is to add a blog post to the database, and how do you know who the author is of this blog post? It is current_user.id

Another important method is logged_in? It merely returns whether current_user is equal to false or nil. (Technically, it does a !!current_user, which is to booleanize the value to true or false. In Ruby, only a false or nil will become false that way. Any other value will become true). So when you need to understand how the whole system works when it comes to logged_in?, merely think about current_user == false or nil is the comparison it does.

If you ever need to change Restful Authentication in any way, such as adding log in using OpenID, or using OmniAuth, or JanRain (log in using Facebook, Twitter, Gmail, AOL, Yahoo account, etc), or Facebook Connect, then it is important to understand how Restful Authentication works.

The most important element there is to understand that current_user checks against 3 things:

1. The user id stored in the Rails session (cookie or in DB, or in any other mechanism). This is how a page request to the next page request keep remembering who the user is, until the user closes and exit the browser, at which time the session will go away.

2. HTTP Basic Authentication. We can skip this part usually, because it uses a rare authenticated system which you see sometimes a website pops up an application window asking you for username and password, and won't show content if it is not. (it'd probably say 401 - Unauthorized)

3. If the user exits the browser (or turn off the computer and come back an hour later or 2 days later), then if the user actually checked the checkbox "Remember me" when that user logged in previously, then there is a "remember me" cookie. This cookie has a value which can be checked against the remember_me field in the users table. It they match, then the Restful Authentication will also think the user has come back and let current_user return this user. The name of this cookie usually is auth_token.

Also worth noting is that when the current_user needs to be set (if you are modifying Restful Authentication), then use self.current_user = a_user. Look into the code -- a good portion of the code is in your project after you run the Restful Authentication generator (when you or somebody who ran it long time ago):

lib/authenticated_system.rb

If you Google for any more info, note that the module name is AuthenticatedSystem.