I need to implement fine-grained access control in a Ruby on Rails app. The permissions for individual users are saved in a database table and I thought that it would be best to let the respective resource (i.e. the instance of a model) decide whether a certain user is allowed to read from or write to it. Making this decision in the controller each time certainly wouldn’t be very DRY.
The problem is that in order to do this, the model needs access to the current user, to call something like
. Models in general do not have access to session data, though. may_read
?(current_user
, attribute_name
)
There are quite some suggestions to save a reference to the current user in the current thread, e.g. in this blog post. This would certainly solve the problem.
Neighboring Google results advised me to save a reference to the current user in the User class though, which I guess was thought up by someone whose application does not have to accommodate a lot of users at once. ;)
Long story short, I get the feeling that my wish to access the current user (i.e. session data) from within a model comes from me doing it wrong.
Can you tell me how I’m wrong?
I'd say your instincts to keep current_user
out of the model are correct.
Like Daniel I'm all for skinny controllers and fat models, but there is also a clear division of responsibilities. The purpose of the controller is to manage the incoming request and session. The model should be able to answer the question "Can user x do y to this object?", but it's nonsensical for it to reference the current_user
. What if you are in the console? What if it's a cron job running?
In many cases with the right permissions API in the model, this can be handled with one-line before_filters
that apply to several actions. However if things are getting more complex you may want to implement a separate layer (possibly in lib/
) that encapsulates the more complex authorization logic to prevent your controller from becoming bloated, and prevent your model from becoming too tightly coupled to the web request/response cycle.