1. Computing

Things to Notice About this Application

By

What's Going on Here?

  • There is no distinction between GET and POST requests. Any action is accessible with either GET or POST, and the application code doesn't do anything differently depending on the type of request. This breaks the GET non-idempotency rule by exposing actions that should be accessible only by POST. Though there is nothing to protect the POST actions from GET requests, there is still a clear distinction in what the actions do. The idempotent actions are index, new, edit and show. These actions only retrieve objects from the database, they never create new objects, delete objects or change attributes of any of the objects. The non-idempotent actions are create, update and delete. These are the actions that should be accessible only through POST.

  • This application uses the acts_as_authenticated plugin to provide authentication. The acts_as_authenticated plugin generates a users table with hashed and salted passwords, a tried and true method of storing passwords for authentication. The plugin also provides a Users controller for registration, login and logout. And, most importantly, the plugin provides a method called login_required that can be used as a before making actions inaccessible unless logged in. If an attempt is made to access a method protected by login_required, the user will be redirected to the login page instead.

  • The login_required before filter is used correctly to protect non-idempotent actions--or actions that exist only to display forms for non-idempotent actions such as new and edit-- from authorized access by using a whitelist. The :except option to before_filter will filter all actions except those listed. If new actions are added to the Posts controller, they will be automatically protected by login_required.

    1. About.com
    2. Computing
    3. Ruby
    4. Ruby on Rails
    5. Security
    6. A Look at Security Risks in Ruby Code

    ©2014 About.com. All rights reserved.