Clone this wiki locally
Acl9 is yet another solution for role-based authorization in Rails. It consists of two subsystems which can be used separately.
Role Subsystem allows you to set and query user roles for various objects.
Access Control Subsystem allows you to specify different role-based access rules inside controllers.
A bunch of access rules is translated into a complex
boolean expression. Then it's turned into a lambda or a method and can
be used with
before_filter. Thus you can block unprivileged access to certain
actions of your controller.
Authorization is not authentication!
Both words start with "auth" but have different meaning!
Authentication is basically a mapping of credentials (username, password) or OpenID to specific user account in the system.
Authorization is an authenticated user's permission to perform some specific action somewhere in the system.
Acl9 is a authorization solution, so you will need to implement authentication by other means. I recommend Authlogic for that purpose, as it's simple, clean and at the same time very configurable.
Role is an abstraction. You could directly assign permissions to user accounts in your system, but you'd not want to! Way more manageable solution is to assign permissions to roles and roles further to users.
For example, you can have role called admin which has all available permissions. Now you may assign this role to several trusted accounts on your system.
Acl9 also supports the notion of object roles, that is, roles with limited scope.
Imagine we are building a magazine site and want to develop a permission system. So, what roles and permissions are there?
Journalists should be able to create articles in their section and edit their own articles.
Section editors should be able to edit and delete all articles in their sections and change the published flag.
Editor-in-chief should be able to change everything.
We clearly see that journalists and section editors are tied to a specific section, whereas editor-in-chief is a role with global scope.
All permission checks in Acl9 are boiled down to calls of a single method:
That should be read as "Does subject have role on object?".
Subject is an instance of a User, or Account, or whatever model you use for authentication. Object is an instance of any class (including subject class!) or nil (in which case it's a global role).
Acl9 builtin role control subsystem provides has_role? method for you, but you can also implemented it by hand (see Coming up with your own role implementation below).