Ruby on Rails seems to be driving more and more toward RESTful programming. However, my search for ideas on how to make a truly RESTful authentication system came up pretty dry. I either found systems that were not as RESTful as I wanted or far to complex then I deemed necessary. As such, I gave some thought on how to make my own.
The result was creating a very simple, flexible and RESTful system. By seeing how I made it, you will also learn more about RESTful programming, understand how to use it within Rails and experience how it keeps your code base lean and clean.
A REST Primer
REST (Representational State Transfer) is a programming concept in which you build your web application to only process basic CRUD (Create Read Update and Delete) operations. This limitation may make RESTful programming difficult at first; however, the benefits are well worth the learning curve. First, your program will have much less code overall, especially in your controllers. Secondly, your code will be much easier to read, which is very important when other developers start working with your code base. Finally, as Ruby is fully object oriented, it makes sense that well developed models (which are objects) should only require CRUD operations anyway. As such, RESTful programming will feel much more natural as you continue working with Ruby.
At the end of the day, all of this will make for a more organized and flexible code base.
Start your Rails project and generate your Session and Person resources
Now, edit your database.yml file, create your database and start your server.
It is now time to build your migrations, starting with the Sessions table. Take notice of the ip_address and path attributes, which will help you keep track of your users as they login and move throughout your application.
Next, is the People table. For security purposes, your application will encrypt passwords with a salt unique to each user.
Now that your migrations are programmed, migrate your database with the rake command.
The Session Model
First, your Session model will authenticate a user by finding a matching name and password in the People table. If a match is found, it will then associate a Session to an authenticated user and then save itself in the database. However, if a matching name and password cannot be found, a request to create a new Session should not pass validation.
During updates, a Session should not be authenticated nor validated as it is already associated to a user and doing so would be unnecessary.
The Person Model
To err on the side of security, your Person model will encrypt every password with a 256 bit SHA2 digestion algorithm accompanied with a unique salt. As users will want to login from many computers, a Person will have many Sessions; all of which must be destroyed if a user unregisters from your application.
Usernames must be simple and unique. Passwords must be 4 to 16 standard ASCII characters and also be confirmed. Next, scrub out any capital letters from the name before saving and then flush the unencrypted passwords afterwards. Finally, passwords should only be validated during updates if a new password is given as a parameter.
In order to take advantage of RESTful routing, you will need to describe your resources in your routes.rb file. While you are there, also set your root_url to the index action of your People Controller. Then, comment out your unrestful paths, as you will not be using them.
NOTE: Remember to delete your public/index.html file as you are setting a new root_url path.
The Application Controller
Maintaining the session is the first duty of your Application Controller. Once logged in, the user’s current session should keep track of their IP address and current path. In order to easily access a user’s account and session information throughout your application, you will also create the @user and @application_session variables. Note that you are calling it @application_session and not @session. This differentiation ensures that a user’s session information is never overwritten by the Sessions Controller.
To ensure users do not get an error if you delete a Session from the database that they have a cookie for, you should also have a quick check to see if the requested session can even be found. If not, just delete the user’s cookie and redirect them back home.
The final order of business is to ensure users are logged in or out before accessing certain actions. Making these methods in the Application Controller and calling them with filters is the easiest way to do so.
The Sessions Controller
Creating and destroying sessions is how users will login and out. As your models are pretty smart, a simple controller is all that is necessary to accomplish this.
The People Controller
Continuing with your pattern of simple controllers is the People controller. With its seven actions, users will be able to register, view other users, edit their account and unregister.
The final part is building the views, all of which are pretty simple.
That is all there is to it. You should now have a very good starting point to further build onto in regards to making your own RESTful authentication system. As you saw, smart models only needed basic CRUD actions, which kept your controllers clean and simple. As such, your code base remains very organized and flexible, priming your application for more advanced features and easier maintenance.