Home arrow Ruby-on-Rails arrow Page 2 - Login Systems and More with Ruby on Rails

Login Systems and More with Ruby on Rails

In this third article of a six-part series covering web development and Ruby on Rails, you'll learn how to add some very desirable features to your web application. This article is excerpted from chapter 15 of the Ruby Cookbook, written by Lucas Carlson and Leonard Richardson (O'Reilly, 2006; ISBN: 0596523696). Copyright 2006 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.

Author Info:
By: O'Reilly Media
Rating: 4 stars4 stars4 stars4 stars4 stars / 39
April 05, 2007
  1. · Login Systems and More with Ruby on Rails
  2. · 15.9 Storing Hashed User Passwords in the Database
  3. · 15.10 Escaping HTML and JavaScript for Display
  4. · 15.11 Setting and Retrieving Session Information

print this article

Login Systems and More with Ruby on Rails - 15.9 Storing Hashed User Passwords in the Database
(Page 2 of 4 )


The database table defined in Recipe 15.8 stores users' passwords as plain text. This is a bad idea: if someone compromises the database, she will have all of your users' passwords. It's best to store a secure hash of the password instead. That way, you don't have the password (so no one can steal it), but you can verify that a user knows his password.


Recreate the users table from Recipe 15.8 so that instead of a password field, it has a hashed_password field. Here's some MySQL code to do that:

  use mywebapp_development;
  CREATE TABLE `users` (
`username` VARCHAR(255) NOT NULL,
`hashed_password` VARCHAR(40) NOT NULL,

Open the file app/models/user.rb created in Recipe 15.8, and edit it to look like this:

  require 'sha1'

  class User < ActiveRecord::Base
attr_accessor :password
attr_protected :hashed_password
validates_uniqueness_of :username
    validates_confirmation_of :password,
      :if => lambda { |user| user.new_record? or not user.password.blank? }
    validates_length_of :password, :within => 5..40,
      :if => lambda { |user| user.new_record? or not user.password.blank? }

    def self.hashed(str)

    # If a user matching the credentials is found, returns the User object.
    # If no matching user is found, returns nil.
    def self.authenticate(user_info)
user = find_by_username(user_info[:username])
      if user && user.hashed_password == hashed(user_info[:password])
        return user

    before_save :update_password

    # Updates the hashed_password if a plain password was provided.
    def update_password
      if not password.blank?
        self.hashed_password = self.class.hashed(password)

Once you do this, your application will work as before (though you'll have to convert any preexisting user accounts to the new password format). You don't need to modify any of the controller or view code, because the User.authenticate method works the same way it did before. This is one of the benefits of separating business logic from presentation logic.


There are now three pieces to our user model. The first is the enhanced validation code. The user model now:

  1. Provides getters and setters for the password attribute.
  2. Makes sure that the hashed_password field in the database can't be accessed from the outside.
  3. Ensures that each user has a unique username.

When a new user is created, or when the password is changed, User ensures:

  • That the value of the password_confirmation attribute is equal to the value of the password attribute.
  • That the password is between 5 and 40 characters long.

The second section of code defines User class methods as before. We add one new class-level method, hashed, which performs the hashing function on a plaintext password. If we want to change hashing mechanisms in the future, we only have to change this method (and migrate any existing passwords).

The third piece of code in the model is a private instance method, update_password, which synchronizes the plaintext password attribute with the hashed version in the database. The call to before_save sets up this method to be called before a User object is saved to the database. This way you can change a user's password by setting password to its plaintext value, instead of doing the hash yourself.

See Also

  1. Recipe 13.14, "Validating Data with ActiveRecord"
  2. Recipe 15.8, "Creating a Login System"

blog comments powered by Disqus

- Ruby-on-Rails Faces Second Security Flaw in ...
- Ruby 2.0 Prepped for February 2013 Release
- Why LinkedIn Switched from Ruby on Rails
- Adding Style with Action Pack
- Handling HTML in Templates with Action Pack
- Filters, Controllers and Helpers in Action P...
- Action Pack and Controller Filters
- Action Pack Categories and Events
- Logging Out, Events and Templates with Actio...
- Action Pack Sessions and Architecture
- More on Action Pack Partial Templates
- Action Pack Partial Templates
- Displaying Error Messages with the Action Pa...
- Action Pack Request Parameters
- Creating an Action Pack Registration Form

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials