declarative authorization filter_access_to

I am attempting to secure a Rails3 controller using declarative_authorization.

The controller has the 7, RESTful actions, three custom member actions (activate, deactivate, copy), and one custom collection action (public). The 'public' action only returns one record, however.

Only the custom collection action (public) should be available to authenticated users; the remainder are only available to the current_user.

has_permission_on :foos, :to =>  :public
has_permission_on :foos, :to =>  [:full_control, :copy, :activate, :deactivate] do
  if_attribute :user => is {user}
end

privilege :full_control, :includes => [:index, :show, :new, :create, :edit, :update, :destroy]

The 4 custom actions are defined in the routes.rb file:

resources :users do
  resources :foos do
    collection do 
      get :public
    end
    member do
      post :activate, :copy, :deactivate
    end
  end
end

A User :has_many Foos; A Foo :belongs_to a User.

The 'standard' access control (filter_resource_access :nested_in => :user), as defined in the FoosController seems to control access to the 7, RESTful actions, but fails to control access to the other 4 (as expected).

When I change the FooController to:

filter_access_to :all, :nested_in => :users, :attribute_check => true

I get an error that reads "Couldn't find Foo without an ID".

Questions:

1. The documentation seems to suggest that a :before_filter will be called automatically to load the Foo model when filter_access_to is used. Am I mistaken? Do I need additional configuration of the filter_access_to? Do I need to manually configure a :before_filter?
2. Do I also need to add using_access_control to the model for my purposes? 开发者_开发百科I'm a little unclear when one needs to add access control to the model when there is access control in the controller.
3. The documentation describes a privilege named 'create'--it is defined as: privilege :create, :includes => :new. In addition, to the :new action, does this privilege automatically include the :create action as a consequence of its name?
4. If the authentication_rules.rb file is changed, does the server need to be restarted for the new rules to be applied?

I think that automatic before filter, if it exists, is pretty limited. I've always had to write my own before filters as appropriate to the context. Eg--for the the index view unless permission is the same for all instances of the model, you'll need to have a model instance appropriate the the current context. Like a user viewing an index of posts, you would want to make a dummy new post for the user, or load their first but dummy is safer since first might not exist. Generally I have a dummy constructor for index and everything else can test whatever is actually to be seen (or touched).

Controller has been good enough for me so far, so model level is certainly not REQUIRED. That's not to say it wouldn't add some extra safety, but I'm not expert in when exactly that would become important. I'd hypothesize it would be when you have a model touched by many controllers (eg modeless controllers) and you want to be sure nothing sneaks by.

I haven't used privileges so I'm not sure, but I would guess that magic inheritance you describe doesn't happen. Creating permissions that aren't specifically requested seems like it would be a very sloppy approach.

No, no restart required--at least not in development mode.