h1. lockdown h1. → 'lockdown' h3. Lockdown has not been officially released! This page is a Work-In-Progress. The first version will be released by May 1st. h2. What Lockdown is a authentication/authorization system for RubyOnRails and Merb designed for simplicity and extensibility. All access rules are defined in lib/lockdown/init.rb. With the included ORM support (ActiveRecord or DataMapper) and management screens you can add user defined rules to the system. If there is a "spec" directory, a test helper file will be included to provied some basic functionality for use with RSpec. This will show you how to create mock user objects and sign in as an adminstrator. Also included is functionality to auto-populate created_by and updated_by fields. Some model level access right functionality will also be added in the near future. h2. Installing For the people who don't care to know the details and just want to get the system installed:
$ sudo gem install lockdown
$ cd 
$ lockdown .
This will create a "lockdown" directory in the lib dir add two files: init.rb and session.rb. Modify init.rb to set defaults and define the rules that apply to your system. If you want the full 'subsystem' (models, views, controllers, helpers):
$ cd 
$ ./script/generate lockdown_all
I recommend reading this page to get a feel for Lockdown's functionality. h2. How it works Lockdown stores an array of access rights in the session. For example, if you have a standard REST users controller, the access rights would be:
  users/index
  users/show
  users/edit
  users/update
  users/new
  users/create
  users/destroy (delete for Merb)
The above list will be stored in the session as an array and each request is tested against this list. So this means, you should not use client side session storage. If you can, I recommend using memcache, but a database session store will suffice. To define access rights you need to modify lib/lockdown/init.rb. This is the default init.rb included with Lockdown:
require "lockdown"
require File.join(File.dirname(__FILE__), "session")

Lockdown::System.configure do 

  #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  # Configuration Options
  #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  # Options with defaults:
  #
  # Set timeout to 1 hour:
  #       options[:session_timeout] = (60 * 60)
  #
  # Set system to logout if unauthorized access is attempted:
  #       options[:logout_on_access_violation] = false
  #
  # Set redirect to path on unauthorized access attempt:
  #       options[:access_denied_path] = "/"
  #
  # Set redirect to path on successful login:
  #       options[:successful_login_path] = "/"
  #
  #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  # Define permissions
  #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  #
  # set_permission(:product_management, all_methods(:products))
  #
  # :product_management is the name of the permission which is later
  # referenced by the set_user_group method
  #
  # :all_methods(:products) will return an array of all controller actions
  # for the products controller
  #
  # if products is your standard RESTful resource you'll get:
  #   ["products/index , "products/show",
  #    "products/new", "products/edit",
  #    "products/create", "products/update",
  #    "products/destroy"]
  #
  # You can pass multiple parameters to concat permissions such as:
  #      
  #	  set_permission(:security_management,all_methods(:users),
  #                                       all_methods(:user_groups),
  #                                       all_methods(:permissions) )
  #
  # In addition to all_methods(:controller) there are:
  #
  #       only_methods(:controller, :only_method_1, :only_method_2)
  #
  #       all_except_methods(:controller, :except_method_1, :except_method_2)
  #
  # Some other sample permissions:
  # 
  #  set_permission(:sessions, all_methods(:sessions))
  #  set_permission(:my_account, only_methods(:users, :edit, :update, :show))
  # 
  #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  # Built-in user groups
  #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  #  You can assign the above permission to one of the built-in user groups
  #  by using the following:
  # 
  #  To allow public access on the permissions :sessions and :home:
  #    set_public_access :sessions, :home
  #     
  #  Restrict :my_account access to only authenticated users:
  #    set_protected_access :my_account
  #
  #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  # Define user groups
  #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  #
  #  set_user_group(:catalog_management, :category_management, 
  #                                      :product_management) 
  #
  #  :catalog_management is the name of the user group
  #  :category_management and :product_management refer to permission names
  #

  # Add your configuration below:
end 
h2. Some History Lockdown was initially designed as a authentication/authorization system to be configured by system administrators. This means it was database driven and had an interface to manage the access rights. I didn't like the static methodology of using code scattered amongst the controllers to define my access rights for the system. I also didn't like the fact that everything was accessible unless you restricted access. So, I designed Lockdown to restrict access to all resources unless rights have been granted. The system was nice and worked well until I had a project that required RSpec tests. I don't have anything against testing frameworks (now that I've see the light) but what bothered me most what the fact that I would have to duplicate the information I already defined in my migrations as mock data. I simply refused to do that extra work. So, a serious refactoring of Lockdown was required. After the RSpec project was completed, the refactoring continued. This time the focus was on releasing the code to the masses. I like this system a lot and think both the system itself and the community could benefit from releasing this as an open source project. In the middle of my refactoring for a public release, I made the decision to use Merb (when the choice was mine). This meant I needed to modify Lockdown for use with Merb. So this is what I have done. There is code in place for using Lockdown with Rails, after all, that's where Lockdown was born. However, I have not yet tested the Rails functionality after this last refactor. In addition, the deployment mechanism for Rails has to be tested. Writing code for public release is difficult and much different from architecting/coding for a closed source project. A lot of things you could get by with in a proprietary application won't be well received by the general public. In addition, if you don't make things easy, the adoption rate will probably be non-existent. h2. Forum If you are having a problem understanding how to use Lockdown, please post your question on the lockdown group. If it's documentation related, I will keep this page updated to help everyone. "http://groups.google.com/group/stonean_lockdown?hl=en":http://groups.google.com/group/stonean_lockdown?hl=en h2. How to submit patches The Clone URL: git://github.com/stonean/lockdown.git Read the "8 steps for fixing other people's code":http://drnicwilliams.com/2007/06/01/8-steps-for-fixing-other-peoples-code/ and for section "8b: Submit patch to Google Groups":http://drnicwilliams.com/2007/06/01/8-steps-for-fixing-other-peoples-code/#8b-google-groups, use the Google Group above. I'm new to git and this whole opensource project admin gig, so please be patient with my stumbling around. h2. License This code is free to use under the terms of the MIT license. h2. Contact Comments and suggestions are welcome via the "forum":http://groups.google.com/group/stonean_lockdown?hl=en