2

我正在尝试使用 declarative_authorization 保护 Rails3 控制器。

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

只有自定义收集操作（公共）对经过身份验证的用户可用；其余的仅对 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]

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

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

一个用户：has_many Foos; 一个 Foo :belongs_to 一个用户。

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。此外，对于 :new 操作，此权限是否会自动包含 :create 操作作为其名称的结果？
  4. 如果更改了 authentication_rules.rb 文件，是否需要重新启动服务器才能应用新规则？
4

1 回答 1

0

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

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

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

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

于 2012-05-24T21:56:17.673 回答