So, I’ve implemented some permissions between my users and the objects the users modify.. and I would like to lessen the coupling between the views/controllers with the models (calling said permissions). To do that, I had an idea: Implementing some of the permission functionality in the before_save / before_create / before_destroy callbacks. But since the permissions are tied to users (current_user.can_do_whatever?), I didn’t know what to do.
This idea may even increase coupling, as current_user is specifically controller-level.
The reason why I initially wanted to do this is:
All over my controllers, I’m having to check if a user has the ability to save / create / destroy. So, why not just return false upon save / create / destroy like rails’ .save already does, and add an error to the model object and return false, just like rails’ validations?
Idk, is this good or bad? is there a better way to do this?
Let the controller check the user’s privileges. To have the model handle authorization logic would lead to more coupling (just in different places, and there’d still be coupling to the controller to get the current user). Checking privileges isn’t really internal logic to a model.
Simile: Imagine if it was a file’s responsibility to check whether you can read/write to it, instead of having the OS (which is the mother of all controllers, really) handle the access.
If you want cleaner controllers you can (for instance) make some generalized before_filters that restrict access to CRUD actions based on the current user.