lockdown
Get Version
0.2.0→ ‘lockdown’
Lockdown has not been officially released! This page is a Work-In-Progress. The first version will be released by May 1st.
What
Lockdown is a authentication/authorization system for RubyOnRails and Merb designed for simplicity and extensibility. All access rules are in (initially) defined in lib/lockdown/access.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.
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 <your_project_directory> $ lockdown .
This will create a “lockdown” directory in the lib dir add two files: access.rb and session.rb. Modify access.rb to define the rules that apply to your system.
I recommend reading this page to get a feel for Lockdown’s functionality.
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/access.rb. This is the default access.rb included with Lockdown:
require "lockdown" module Lockdown # # # Permissions are used to group access rights into logical components. # Each method defined in the Permissions module represents an array # of methods from a controller (or multiple controllers.) # # Controller methods available are: # # # Returns all methods from all controllers # all_controllers # # # Returns all methods from all controllers listed # all_methods :controller1, controller2, ... # # # For a single controller, returns only methods listed # only_methods :controller1, :method1, :method2, ... # # # For a single controller, returns all methods except the methods listed # all_except_methods :controller1, :method1, :method2, ... # # They all return an array of controller/action. For example, if you had a # standard REST controller called products this would be the result: # # # all_methods :products => [ "products/index , "products/show", # "products/new", "products/edit", # "products/create", "products/update", # "products/destroy"] # module Permissions class << self def sessions_management # all_methods :sessions end end # end class block end # end Permissions module # # UserGroups are used to group Permissions together to define role type # functionality. Users may belong to multiple groups. # module UserGroups class << self # # This method defines which UserGroups cannot be managed # via the management screens. # # Users can still be assigned to these groups. # def private_records [:administrators] end # # This method defines which UserGroups have limited access # via the management screens. Deletion is not allowed. # # Users can still be assigned to these groups. # def protected_records [:public_access, :registered_users] end # ** The administrator method is "special", please don't rename. # If you remove/rename, etc... YOU WILL BREAK STUFF # # Standard administrator user group. # Please don't alter without careful consideration. # def administrators [:all] end # ** The public_access method is "special", please don't rename. # If you remove/rename, etc... YOU WILL BREAK STUFF # # Standard public_access user group. # # Feel free to add Permissions to the array without issue. # # **Notice: All permissions added to this public_access group will not be # restricted to logged in users. # So be careful what you add here! # def public_access [:sessions_management] end # ** The registered_users method is "special", please don't rename. # Not as special as the others, but still... # # All newly created users are assigned to this User Group by default # def registered_users #[:my_account] end # # Define your own user groups below # end # end class block end # end UserGroups module end # end Lockdown module
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.
This is where the access.rb file was born. This file contains the rules that grant/deny access to your system. More on this later.
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.
Features
I have these components (for the most part)...figuring out how to package them. The following is just an idea right now…
The goal of Lockdown is to give you only what you want from the system.
The initial install is all that is required to lock down your system. However, you’ll probably want the authorization functionality. You can get this by:
rake lockdown:install:authorization
If you want to install ORM support:
rake lockdown:install:orm
If you want to install management screens (ORM support included):
rake lockdown:install:management
If you want to install authorization + management screens:
rake lockdown:install:all
Forum
http://groups.google.com/group/stonean_lockdown?hl=en
How to submit patches
The Clone URL: git://github.com/stonean/lockdown.git
Read the 8 steps for fixing other people’s code and for section 8b: Submit patch to 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.
License
This code is free to use under the terms of the MIT license.
Contact
Comments and suggestions are welcome via the forum
22nd April 2008
Theme extended from Paul Battley