At the Forge - Authenticating to a Rails Application

Do you wish that Rails came with more built-in functionality? Plugins bridge this gap, offering solutions to many common problems.
Installing acts_as_authenticated

To install a new plugin—say, acts_as_authenticated—we must provide its URL to script/plugin. This is as easy as the following:

script/plugin install

Now, what happens when you install a plugin? Rails installs it into the vendor/plugins directory, under a new directory named after the plugin. Thus, my installation of acts_as_authenticated installed a number of files into vendor/plugins/acts_as_authenticated.

In and of itself, installing the plugin doesn't change my Rails installation or add any new functionality. Rather, a plugin typically creates one or more generators, which are used to create or modify files used by the application.

In the case of acts_as_authenticated, it comes with two different generators, which we can see by going into the generators subdirectory. Here, there are two generators, named authenticated and authenticated_mailer. If we go into the authenticated directory, we see authenticated_generator, which is what defines the generator. This allows us to go to the root directory of our Rails application and type:

script/generate authenticated user account

The above tells Rails that we want to use the authenticated plugin, which it finds in the plugin directory. The other arguments to this command indicate the model (and table name) we will use (user in this case), and the controller that should be generated to handle accounts.

The generator creates a migration file, defining the columns of the Users table using Ruby for greater database independence. In order to create the columns of the database, we must run the migration:

rake db:migration

Using my PostgreSQL database client, I now can see that the migration did its job:

atf_development=# \d users
                     Table "public.users"
          Column           |            Type             |
 id                        | integer                     |
 login                     | character varying(255)      |
 email                     | character varying(255)      |
 crypted_password          | character varying(40)       |
 salt                      | character varying(40)       |
 created_at                | timestamp without time zone |
 updated_at                | timestamp without time zone |
 remember_token            | character varying(255)      |
 remember_token_expires_at | timestamp without time zone |

Using the Plugin

Now that I have incorporated acts_as_authenticated into my application, I should be able to do several simple things:

  1. Mark pages as open to the public.

  2. Mark pages as private—that is, open only to registered users.

  3. Allow people to register.

  4. Allow users to log in.

  5. Allow users to log out.

All of this is not only possible with acts_as_authenticated, but it's also quite easy. To make pages require authentication by default, we can say:

before_filter :login_required

Of course, if we require that people log in before they use the login page, users will find themselves in an infinite loop. So, we can add an exception for that at the top of account_controller.rb:

before_filter :login_required, :except => [:login, :signup]

Once this filter is in place, trying to visit any page other than login or :signup bounces us back to the login page.

I'm going to register, by entering my login name, my e-mail address and my password (twice) into the registration form. Once I click on the submit button, the application inserts my data into the database. I'm in there, with ID #1, and my plain-text data as well as my encrypted data.

Moreover, after registering with the site, I am now signed in as well. I can view any page I want, without having to log in again. My login will last until I go to the /account/logout URL. Unfortunately, the default index.rhtml page that comes with acts_as_authenticated does not make it clear when you have logged out. We can check that easily by adding a line to the top, showing the contents of non-blank notices:

<p><%= flash[:notice] if not flash[:notice].blank? %></p>

We now have a basically working version of an authenticated Web server. People can register (and log in if they are already registered), and we can add both restricted and unrestricted pages via the controller and the before_filter :login_required command.


White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState