декларативная авторизация filter_access_to - PullRequest
Новая
       11

декларативная авторизация filter_access_to

2 голосов
/ 11 августа 2010

Я пытаюсь защитить контроллер Rails3 с помощью декларативного_авторизации.

Контроллер имеет 7 действий RESTful, три пользовательских действия члена (активировать, деактивировать, копировать) и одно пользовательское действие сбора (общедоступное). Однако публичное действие возвращает только одну запись.

Только пользовательские действия по сбору (общедоступные) должны быть доступны для аутентифицированных пользователей; остальные доступны только для 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]

В файле rout.rb определены 4 пользовательских действия: 

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

A Пользователь: has_many Foos; Foo: принадлежит_ пользователю.

«Стандартный» контроль доступа (filter_resource_access: nested_in =>: user), как определено в FoosController, похоже, контролирует доступ к 7 действиям RESTful, но не контролирует доступ к другим 4 (как и ожидалось).

Когда я изменяю FooController на: 

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

Я получаю сообщение об ошибке «Не могу найти Foo без идентификатора».

Вопросы:

  1. Документация предполагает, что a: before_filter будет вызываться автоматически для загрузки модели Foo при использовании filter_access_to. Я ошибаюсь? Нужна ли дополнительная настройка filter_access_to? Нужно ли вручную настраивать: before_filter?
  2. Мне также нужно добавить using_access_control в модель для моих целей? Мне немного непонятно, когда нужно добавить контроль доступа к модели, когда в контроллере есть контроль доступа.
  3. В документации описана привилегия с именем 'create' - она ​​определяется как: privilege: create,: includes =>: new. В дополнение к действию: new, включает ли эта привилегия автоматически действие: create вследствие его имени?
  4. Если файл authentication_rules.rb изменяется, нужно ли перезапускать сервер для применения новых правил?

1 Ответ

0 голосов
/ 25 мая 2012

Я думаю, что автоматический фильтр до, если он существует, довольно ограничен. Мне всегда приходилось писать свои собственные фильтры до соответствия контексту. Например, для представления индекса, если разрешение не является одинаковым для всех экземпляров модели, вам нужно иметь экземпляр модели, соответствующий текущему контексту. Как и пользователь, просматривающий индекс сообщений, вы хотите создать фиктивную новую запись для пользователя или загрузить первую, но фиктивная безопаснее, поскольку первая может не существовать. Обычно у меня есть фиктивный конструктор для индекса, и все остальное может проверить все, что на самом деле нужно увидеть (или потрогать).

Контроллер был достаточно хорош для меня, поэтому уровень модели, конечно, не ТРЕБУЕТСЯ. Это не значит, что это не добавит дополнительной безопасности, но я не знаю, когда именно это станет важным. Я бы предположил, что это произойдет, если у вас есть модель, которой касаются многие контроллеры (например, немодальные контроллеры), и вы хотите быть уверенным, что ничто не ускользнет.

Я не использовал привилегии, поэтому я не уверен, но я думаю, что волшебное наследие, которое вы описываете, не происходит. Создание разрешений, которые специально не запрашиваются, похоже, будет очень небрежным подходом.

Нет, перезагрузка не требуется - по крайней мере, не в режиме разработки.

...