5 апреля 2012 в 00:22

Heimdallr: защита полей модели и новый CanCan перевод

В процессе превращения большей части web-проектов в браузерные приложения, появляется много вопросов. И один из самых весомых из них – обработка прав доступа без лишнего кода. Размышления на эту тему привели нас к большой проблеме: комфортного способа реализовать защиту на уровне полей модели для ActiveRecord просто нет (Егор, привет! ;). CanCan добавляет ограничения на уровне контроллеров, но это слишком высокий уровень чтобы решить все проблемы.

Немножко пободавшись, мы написали два милых гема. Встречайте, Heimdallr (Хеймдаль) и его расширение Heimdallr::Resource. Они принесут в ваши модели мир и безопасность.

Heimdallr


Давайте для начала рассмотрим проблему глубже. Огромная часть проектов действительно приравнивает безопасность к управлению доступом REST-контроллеров. Большие проекты нередко спускаются к моделям, чтобы не дублировать код. А чтобы число экшнов в контроллерах не стало невыносимо большим, иногда спускаются и к контролю доступа полей.



Для многих RESTful-приложений, 1-й и 2-й уровни идентичны. Поэтому в сухом остатке у нас:

  1. Доступ к моделям
  2. Доступ к полям моделей

При этом важность управления доступом к полям стремительно растет с ростом проекта. И недавний пример с дискредитацией Github – яркий пример последствий подхода «Поля? Да кому это надо!».

Вот пример того, как Heimdallr может помочь с этим:

class Article < ActiveRecord::Base
  include Heimdallr::Model

  belongs_to :owner, :class_name => 'User'

  restrict do |user, record|
    if user.admin?
      # Администратор может делать что угодно
      scope :fetch
      scope :delete
      can [:view, :create, :update]
    else
      # Другие пользователи видят свои и не-секретные статьи
      scope :fetch,  -> { where('owner_id = ? or secrecy_level < ?', user.id, 5) }
      scope :delete, -> { where('owner_id = ?', user.id) }

      # ... и видят все поля кроме уровня секретности
      # (хотя владельцы видет все поля)...
      if record.try(:owner) == user
        can :view
        can :update, {
          secrecy_level: { inclusion: { in: 0..4 } }
        }
      else
        can    :view
        cannot :view, [:secrecy_level]
      end

      # ... а еще они могут их создавать, правда с ограничениями.
      can :create, %w(content)
      can :create, {
        owner_id:      user.id,
        secrecy_level: { inclusion: { in: 0..4 } }
      }
    end
  end
end

Используя простой DSL внутри моделей, мы объявляем как ограничения доступа к самим моделям, так и к их полям. Heimdallr расширяет использующие его модели методом .restrict. Вызов этого метода обернет класс модели в прокси-обертку, которую можно использовать совершенно прозрачно.

Article.restrict(current_user).where(:typical => true)

Обратите внимание, что для вызовов Class.restrict, вторым параметром блока будет nil. Поэтому все проверки, зависящие от состояния полей текущего объекта должны быть обернуты в .try(:field).

Эти ограничения можно использовать в проекте где угодно, не только в контроллерах. И это важно. Если вы попытаетесь прочитать защищенное поле – исключение. Такое поведение предсказуемо, но это не очень удобно для оформления вьюшек.

Чтобы решить проблему с вьюшками, Heimdallr реализует две стратегии, явную и неявную. По умолчанию, Heimdallr будет следовать явной модели поведение. А вот альтернативное поведение:

article  = Article.restrict(current_user).first
@article = article.implicit

@article.protected_thing # => nil

Ок. В начале статьи я упомянул CanCan. Но разве он не решает проблему принципиально иначе?

CanCan


Для многих Rails-проектов термин «Безопасность» является синонимом именно для гема CanCan. CanCan действительно был целой эпохой и до сих пор отлично работает. Но у него есть ряд проблем:

  • CanCan был задуман как инструмент, который не работает с моделями. Он предлагает архитектуру, в которой REST-контроллеры защищены, а до моделей злоумышленник попросту не дойдет. Иногда эта стратегия хороша, иногда нет. Но факт в том, что до полей при этом не добраться, как ни старайся. CanCan попросту не знает и ничего не может знать о полях.
  • Ветка 1.х мертва и не поддерживается. В ней есть несколько неприятных багов, которые препятствуют работе в сложных случаях с namespac'ами. А ветка 2.х разрабатывается непозволительно долго.

Мы начали разработку Heimdallr'я как инструмента контроля моделей, но на практике оказалось, что у нас достаточно данных, чтобы ограничивать и контроллеры. Поэтому мы взяли и написали Heimdallr::Resource.

Эта часть Heimdallr'я мимикрирует под CanCan настолько, насколько это возможно. У вас есть тот же фильтр load_and_authorize и вот как он работает:

  • Если для текущего контекста не объявлен скоуп :create (и следовательно вы не можете создавать сущности), значит вам нельзя в new и create
  • Если у вас нет скоупа :update, нельзя в edit и update.
  • Аналогичный подход для скоупа :destroy
  • В экшны вы получаете сразу защищенную сущность, а следовательно не можете забыть вручную вызвать restrict

Выглядит это так:

class ArticlesController < ApplicationController
  include Heimdallr::Resource

  load_and_authorize_resource

  # если имя контроллера отличается:
  #
  # load_and_authorize_resource :resource => :article

  # для вложенных:
  #
  # routes.rb:
  #   resources :categories do
  #     resources :articles
  #   end
  #
  # load_and_authorize_resource :through => :category

  def index
    # @articles заполняются и restrict'ятся
  end

  def create
    # @article заполняются и restrict'ятся
  end
end

Провайдеры REST-API


В начале повествования, я рассказал о корне идеи, синхронизации прав доступа между клиентским приложением и серверным REST-API. И вот к каким конвенциям мы в итоге пришли.

Представьте, что у вас есть простой CRUD-интерфейс с ролями, который нужно реализовать как клиентское JS-приложение. При этом на сервере у вас есть REST с index/create/update/destroy. Права доступа задают следующие вопросы:

  1. Какие сущности я могу получить через index?
  2. Какие из них я могу менять?
  3. Какие из них я могу удалить?
  4. Могу ли я создать новую сущность?
  5. Какие поля я могу задать при обновлении?
  6. Какие поля я могу задать при создании?

Первый вопрос решается Heimdallr'ом от природы. Вы просто определяется нужный скоуп и все. Никто ничего лишнего просто не видит. Касательно остального. В своей последней статье я рассказал как мы рендерим JSON-представления для REST-провайдеров. Используя эту же технику, вьюху очень легко расширить следующими полями:

{modifiable: self.modifiable?, destroyable: self.destroyable?}

Могу ли я создавать? И с какими полями?


Для REST API метод new практически бесполезен. И это отличное место чтобы определить можем ли мы создавать что-то и что именно. Например так:

Article.restrictions(current_user).allowed_fields[:create]

Если мы не можем создавать вообще, Heimdallr::Resource ответит на этот запрос ошибкой. Иначе мы получим список полей, доступных для заполнения.

Хеймдаль также объявляет метод .creatable?, так что и его можно прокинуть через REST.

Могу ли я обновлять?


Идея аналогична созданию. Только в этот раз мы объявим метод edit:

Article.restrictions(current_user).allowed_fields[:update]

В заключение


Использование Хеймдалля и его расширения, Heimdallr::Resource, поможет легко управлять правами доступа без лишнего мусора в коде. И, что немаловажно, вы получаете дополнительную магию для ваших REST-API. Помните, Хомяков следит за вами!

ಠ_ಠ
Автор: @inossidabile Boris Staal
Round Lake
рейтинг 37,50
Компания прекратила активность на сайте

Комментарии (6)

  • +2
    Грацую ребятУшки!
    Выглядит очень вкусненько. Давно сам подумывал о нечто-подобном. Но вы сделали всё — ещё красивше.
    Спасибо!
  • 0
    Поддерживаю предыдущего оратора, надо срочно опробовать ваше творение.
  • 0
    Чтоб оно ещё с gem'ом orm_adapter работало.

    Скажите, а кешировать по ролям пользователей разве не выгоднее, чем для каждой пары проходить и каждый раз строить заново структуру разрешений?
    • +1
      Да, поддержка orm_adapter'а, в первую очередь ради монгоида – следующая важная веха. Сначала нужны более bulletproof спеки, чтобы ничего никому не сломать :). Но мы думаем в этом направлении, будет.
  • 0
    Спасибо за труды. Выглядит очень здорово ) а в продакшене использовать уже можно?
    • 0
      Мы используем. В последнее время правки шли активно, но мы вроде сделали все, что хотели. Работают даже самые сложные случаи.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка