Рельеф Rails 4

Я смотрю автомат для рельсов 4. Прежде чем я использовал cancan, но он выглядит устаревшим в наши дни...

Я нашел the_role здесь https://github.com/the-teacher/the_role Это почти то, что я хочу, но имеет несколько раздражающих проблем. Может быть, подобные драгоценности существуют? Мне нужны роли, хранить роли в базе данных и действия с правилами. Это будет здорово, если драгоценный камень будет взаимодействовать с бутстрапом.

P.S. Для аутентификации я использую devise.

Ответ 1

CanCanCan

CanCan был популярным камнем для авторизации, разработанной Райаном Бейтсом (наиболее известным для RailsCasts) и оставленным до выпуска Rails 4.0, Благодаря своей популярности проект CanCanCan на уровне сообщества поддерживает обновленную версию CanCan. CanCan предоставляет DSL (специфичный для домена язык), который изолирует всю логику авторизации в одном классе Ability.

Пандит

Значок Pundit приобретает популярность для авторизации Rails. Pundit - это система авторизации, которая использует простые объекты Ruby для правил доступа. Pundit использует папку с именем app/policies/, содержащую простые объекты Ruby, которые реализуют правила доступа.

CanCanCan или Pundit или?

По мере усложнения приложения класс CanCan Ability может стать громоздким. Кроме того, для каждого запроса авторизации требуется оценка всего класса CanCan Ability, что увеличивает накладные расходы. Pundit также предлагает преимущество разделения правил доступа в центральном месте, что делает контроллеры тощими. Объекты политики Pundit являются легкими, добавив логику авторизации без особых затрат, как CanCan.

Простая авторизация на основе ролей

С Rails 4.1 вы можете реализовать авторизацию на основе ролей, используя Active Record Enum. Вы можете использовать CanCanCan или Pundit, чтобы держать контроллеры тощими, если ваши правила доступа сложны, но для простых требований вам может не понадобиться CanCanCan или Pundit.

Я написал статью о

Ответ 2

Вы должны посмотреть на большую картинку даже за пределами Ruby и рассмотреть модель авторизации. Традиционная распространенная модель - это контроль доступа на основе ролей (RBAC), и это то, что реализуется большинством фреймворков и - в Ruby - большинство драгоценных камней.

Но если у вас есть более сложные сценарии, которые вы хотите рассмотреть на основе управления доступом на основе атрибутов и XACML, расширяемый язык разметки контроля доступа.

С помощью XACML вы можете реализовать авторизацию с учетом контекста, основанную на политике. Например, вы можете писать такие правила, как:

  • Менеджеры
  • могут редактировать свои документы.
  • врачи могут просмотреть медицинскую карту пациентов, которым они назначены

И так далее...

Мне не известно о Ruby gem, чтобы применить XACML к вашим проектам Ruby, но характер XACML таков, что вы можете легко реализовать свои собственные агенты авторизации (точки соблюдения). Я написал некоторые из них в PHP, Java,.NET и Perl.

Вам понадобится механизм авторизации. Существует несколько решений с открытым исходным кодом и поставщиков, таких как SunXACML и Axiomatics.

Вот несколько интересных ресурсов:

  • NIST RBAC - официальное определение модели RBAC
  • NIST ABAC
  • OASIS XACML

Ответ 4

Action Access отлично работает с Rails 4, имеет очень четкий синтаксис и действительно легкий.

Это сводится к следующему:

class ArticlesController < ApplicationController
  let :admin, :all
  let :user, [:index, :show]

  # ...
end

Это автоматически блокирует контроллер, позволяя администраторам получать доступ к каждому действию, только пользователям показывать или индексировать статьи, а кто-либо другой будет отклонен и перенаправлен с предупреждением.

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

Для гранулярного управления вы можете использовать not_authorized! внутри действия для проверки данных из базы данных или всего, что вам нужно.

Он полностью независимый системы аутентификации и может работать даже без моделей User или предопределенных ролей. Все, что вам нужно, - установить уровень зазора для текущего запроса:

class ApplicationController < ActionController::Base
  def current_clearance_level
    session[:role] || :guest
  end
end

Вы можете вернуть то, что требуется вашему приложению, например current_user.role.

Он также объединяет набор удобных дополнений моделей, которые позволяют расширить модели пользователей и делать такие вещи, как:

<% if current_user.can? :edit, :article %>
  <%= link_to 'Edit article', edit_article_path(@article) %>
<% end %>

Здесь :article относится к ArticlesController, поэтому ссылка будет отображаться только в том случае, если текущий пользователь имеет право доступа к действию edit в ArticlesController. Пространства имен также поддерживаются.

Вы можете заблокировать контроллеры по умолчанию, настроить путь перенаправления и предупреждающее сообщение и т.д. Оформить дополнительную документацию .

Ответ 5

Pundit и Cancancan - лучшие драгоценные камни для рельсов 4