声明式授权filter_access_to

Question

我正在尝试使用 declarative_authorization 来保护 Rails3 控制器的安全。

该控制器具有 7 个 RESTful 操作、3 个自定义成员操作（激活、停用、复制）和 1 个自定义收集操作（公共）。然而，“公共”操作仅返回一条记录。

只有自定义收集操作（公共）才可供经过身份验证的用户使用；其余的仅对当前用户可用。

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]

4个自定义操作在routes.rb文件中定义：

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; Foo：属于用户。

FoosController 中定义的“标准”访问控制（filter_resource_access :nested_in => :user）似乎控制对 7 个 RESTful 操作的访问，但无法控制对其他 4 个操作的访问（如预期）。

当我将 FooController 更改为：

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

我收到一条错误，内容为“无法找到没有 ID 的 Foo”。

问题：

1. 文档似乎表明，当使用 filter_access_to 时，将自动调用 :before_filter 来加载 Foo 模型。我错了吗？我需要对filter_access_to进行额外配置吗？我需要手动配置 :before_filter 吗？
2. 为了我的目的，我还需要将 using_access_control 添加到模型中吗？当控制器中有访问控制时，我有点不清楚何时需要向模型添加访问控制。
3. 该文档描述了一个名为“create”的权限 - 它定义为：privilege :create, :includes => ：新的。此外，对于 :new 操作，此权限是否会因其名称而自动包含 :create 操作？
4. 如果authentication_rules.rb文件发生更改，是否需要重新启动服务器才能应用新规则？

Answer 1

我认为自动前置过滤器（如果存在的话）是相当有限的。我总是必须根据上下文编写自己的过滤器。例如，对于索引视图，除非模型的所有实例的权限都相同，否则您需要有一个适合当前上下文的模型实例。就像用户查看帖子索引一样，您可能希望为用户创建一个虚拟的新帖子，或者加载他们的第一个帖子，但虚拟的帖子更安全，因为第一个帖子可能不存在。一般来说，我有一个用于索引的虚拟构造函数，其他所有内容都可以测试实际看到（或触摸）的内容。

到目前为止，控制器对我来说已经足够好了，所以模型级别当然不是必需的。这并不是说它不会增加一些额外的安全性，但我不知道什么时候这会变得重要。我假设当你有一个模型被许多控制器（例如无模式控制器）接触并且你想确保没有任何东西偷偷溜过时。

我没有使用过特权，所以我不确定，但我猜你描述的神奇继承不会发生。创建没有特别请求的权限似乎是一种非常草率的方法。

不，不需要重新启动——至少在开发模式下不需要。