there’s a question, I can’t really answer for myself. Let’s assume,
I’ve got a rails application for selling cars. A user can create an
advertisement by choosing the corresponding model from a table
“car_models” and then add additional information. The user should
always be able just to read the “car_models” table, not to change
it. On the other hand, there’s an assistant who administers the
“car_models” table, adding, changing and removing entries.
So, where we are? We have our “CarModel” controller with its CRUD
methods. And, let’s assume, we have a roled based access control
implemented. A normal user is a group member of “STD_USER”, for
example. So he may only access the “get” oder “read” methods,
whatever. The assistant however is member of the group “STD_ADMIN”,
for example, and has access to all methods of our “CarModel”
controller.
Although this looks secure, I must confess, that I am concerned. What
if the RBAC fails for some reasen? What if a normal user gets
accidentally in the admin group?
Wouldn’t it be better to separate those functionalities? Let’s say:
one administration application and one great wide world application.
I’m not convinced myself. How do you handle this?
Yeah, it’s better to separate them, but you’re still going to be in
the same boat as before, really: it’s going to be down to whatever
qualifier you decide to split the access levels on.
Well it all in relations.
CarModel controller - has in info.
has_many :advertisments
All controller actions regarding this model, is garded by if the user
is adminnistrator.
hence in your user model, you put an bool called “admin”.
So all actions in the controller if garded with if @user.admin
For the advertisment you have:
And a belongs_to :carmodel
I use Goldberg (http://wiki.github.com/urbanus/goldberg) to manage
this situation. It’s possible to restrict access to controllers/
actions by roles. So you can forbid edit/update to normal users (or on
the other hand, forbid everything then allow only view for normal
users).
But anyway, you are not protected against a configuration mistake or
any security bug…
I use this approach, too. Moreover I like to separate all admin
controllers in their own namespace. Unfortunately in version 2.2
creating scaffold in namespace creates tables with admin_ (if
namespace is admin) prefix which is annoying and looks to me as a
bug.
Also in your controller you can put:
before_filter :require_admin
where require_admin is a method defined in your application.rb and
returns true if current user has admin flag set.
You can use before_filter in another way to require admin just for
some actions:
