Pundit is a realy simple Ruby Gem, that does nothing more that you could have done yourself. Here is the power !
When updating to Rails 4 in it's early days, you had no compliant authorization solutions.
Ryan Bates's Cancan was the most used due to it's flexibility and simplicity, but it is not Rails 4 compliant, and brings too much magic for me.
But is there something more flexible and simple than the Void ? ( OK, ... I stop with VoidMadness ... )
For one of my current job, I started to build a software that needs flexible right management. ( And also a People relations graph, but this is for another post ).
The requirement are :
* Fined grained activities( or action ) access control
* Fields read / write access control
* Flexible Role based system that allow role inheritance
In this article I'll address only the first requirement, the second will be explained in the next article, while the last one does not need to be since it is obvious.
Let introduce the base models
For each Role, I want to allow some activities. (IE: For accountant : create bill, update payment. For Team Manager : Plan Task for a member of his/her Team )
About Pundit
Pundit set some helpers to :
* Check Policy for a given user on a given object( it is not restricted to ActiveRecord::Base instances ).
* Describe Policy in Ruby Class
* Enforce use of Policy in your controllers
* Bring syntactic sugar in you Rspec tests.
I recommend you to read Pundit's README.md before going further, since I won't explain what is already explained there.
The Activities
If found an interesting post from Derick Bailey about authorization patterns, putting words on some of my thoughts. Reading this is not required to go further, but I recommend to.
The activities is not a finite collection. In fact, from my point of view, activities are defined by the following set : All methods directly exposed to user except.
In the Ruby On Rails world as in many MVC frameworks, this mean all the methods available on controllers. (Authentication Activities is a Subset of this set, that has particularity to be allowed to all users.)
I do not want to have a collection of activities to maintain. I do not want to reify them through an Postgres table or a flat file.
I want that default behavior is to deny. This behavior should be overridden if you have the appropriate role.
Since I'am building a REST API, I want to scope each activity on his resource.
Example:
The Person resource expose through API it's CRUD methods (We will not use HTTP verbs to authorized. I do not find clever to bind Authorization on the Transfer Protocol ).
I see Person activities as the following set :
person:create
person:update
person:delete
person:show
person:index
...
The pattern is dead simple and interpolate as #{resource}:#{activity}
With all those postulates, I decided to store activities on Role through the Postgres Array Type. It will be an array of strings.
Meta-programming Right Management
Then I just had to teach Pundit the way I wan't it to authorize activities :
This may need some explanations :
This is the ApplicationPolicy, it will be inherited by each resource, allowing to extend/ override Policies by resources.
I replaced the bulk Pundits question marked CRUD methods with some meta-programming to avoid code duplication, and tedious declarations.
Line 9 : It recovers allowed activities for the current user.
Line 13 : The current activity against which we authorize is inferred from the object's class name ( the word record is used but i plan to change this, since record mean database record for me, but it could be any object ).
Line 17 : The (in)famous Ruby's method missing !
Any unknown method ending with a question mark in the current scope will be interpreted as a check access right for this activity method.
Each time we want to check access right for an activity, it will lookup the allowed activities for the current user roles ...
This is the way the most of work is done, with a few ruby lines of code.
To manage rights, all we need is to add the activity to user role, what could be more simple ?
The person resource
Since all the work is done by the ApplicationPolicy class, the PersonPolicy class is just there to include and override behaviors.
The application Controller
Nothing extravagant here. Just read comments. Note that when the right are insufficient, It just return a 403 HTTP Header, it is enough for a REST API and is the way I understand the RFC 2616.
The Rspec Tests. ( Behaviour Driven ? )
Just to show how it works and as proof , this is a dumb spec/test for the dumb person example.
The test ouput the following :
Easy :)
In a further post i'll detail how to apply read/write mask on object.
