Philosophical question about MVC

Hi folks,
I am working on Station, a Rails Engine [1] that supports authorization
among
other things.

Using Station, you can ask a model about authorization, for example:

post.authorize?(permission, :to => current_user)

My question rises when doing automatic Model - Controller mapping. How
coupled
should be the action in the controller with the permission authorized in
the
model?

Consider this resource:

class PostsController
authorization_filter
end

This could map the authorization to the post instance this way:

  • create
    Post.new.authorize?(:create, :to => current_user)
  • show
    Post.find(params[:id]).authorize?(:show, :to => current_user)

I am not sure that the Controller actions should be mapped directly to
the
Model permissions. There are cases when an action requires several
permissions, like:

  • edit
    Post.find(params[:id]).authorize?(:show, :to => current_user) &&
    Post.find(params[:id]).authorize?(:update, :to => current_user)

Maybe this mapping could be declared in the controller, maybe in the
model…

Can anyone shed light on this?

[1] http://rstation.wordpress.com

Antonio Tapiador del Dujo wrote:

Hi folks,
I am working on Station, a Rails Engine [1] that supports authorization
among
other things.

Using Station, you can ask a model about authorization, for example:

post.authorize?(permission, :to => current_user)

My question rises when doing automatic Model - Controller mapping. How
coupled
should be the action in the controller with the permission authorized in
the
model?

Philosophically, I agree with Ryan B.’ approach in CanCan, which is
to decouple authorization from everything, including all three layer of
MVC.

http://github.com/ryanb/cancan

I say “philosophically” since I have not add the opportunity to
implement CanCan in any of my projects yet.

Very interesting solution. And pretty similar to Station, btw.

Many thanks for the link Robert!

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs