TheRole 3. Авторизация для Ruby on Rails

[@arni]

К сожалению не обнаружил хотя бы минимального сравнения с CanCan, раз последний — стандарт де-факто. Самого ожидает окунание в мир гемов авторизации, поэтому искал этот момент.

p.s.

Стиль изложения выдаёт в авторе продукт высшей школы (неоконченая аспирантура?): огромная вводная часть о мироощущении и гармонии вселенной, и только к середине статьи начинается бодрое деловое изложение. Текст для технического ресурса типа хабра надо сушить со сташной силой, благо сам ruby — образчик лаконичности. Прошу прощения за критику, но сам такой.

[@zayko]

неоконченая аспирантура?

o_O Ну да, я не защищался, за отсутствием какого-либо влияния на мое будущее. Но сделать такой вывод из статьи — это сильно :D

не обнаружил хотя бы минимального сравнения с CanCan

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

[@Envek]

CanCan хорош для маленьких приложений, в больших же класс Ability жутко разрастается. Мы перешли на Pundit так как с ним можно работать гибче: в Policy-классе можно и скоупы строить, чтобы в контроллере показывать только доступные пользователю записи и каким-нибудь методом строить список полей для Strong Parameters, чтобы бесправный пользователь не мог случайно поменять то, что ему не положено в модели.

[@LimeOrange]

Пытался найти вменяемый перевод фразе «I second that!», но лучшее, к чему пришел — «полностью согласен». Когда в приложении пара сотен контроллеров, а пользователи разбиты на десяток разных групп (различия между которыми отличаются не более чем десятком контроллеров) — прагматик во мне испытывает невыносимую попоболь. В итоге сделали внутренний патч, позволяющий через LDAP группы присваивать пользователям более 1 ruleset'а.

Если будет время, и если автор не против, сделаю потом форк с habtm-ролями.

[@zayko]

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

[@NikMelnikov]

Архитектура с этими двумя операциями вполне себе оправдана.
{quote}Владение — обычно мы хотим, что бы пользователь имел возможность исполнения важных операций только над теми объектами, которые ему принадлежат. Т.е. между пользователем и объектом есть некоторый признак принадлежности (владения). Что бы попасть в номер отеля вам нужно иметь ключ
Доступность операции — как правило определяется через ACL. Т.е. в неком хранилище есть информация о том, может ли данный пользователь в принципе исполнять некоторое действие. В деканате есть список студентов, которым можно сдавать экзамен {quote}

1) «Владение. „Как пример, в нашем проверенном годами фреймворке для классов тоже можно поставить галку “авторские права». Это значит, что при работе с объектом будет проверяться роль у пользователя «Автор», а у объекта соответствующее поле «Автор». Если совпадает, значит все привилегии ему на стол.
У вас я так понимаю то же самое. Правда за кадром осталось, кто отвечает за обновление поля USER_ID заданного объекта. Ваш гем или разработчик сам должен об это задуматься при действиях create.

2) Доступность операции. Здесь тоже понятно. Стандартный Access List с набором возможных действий и ролями, которые данные действия могут выполнять. Только у нас более наворочено, т.к. проверяться могут отдельные поля, группы полей и т.д.

[@Renius]

1) гем только проверяет, странно ожидать что гем будет отвечать за консистентность

[@NikMelnikov]

я догадываюсь. Просто для новичков это может быть совсем неочевидно, и об этом надо писать.

[@Renius]

Это конвенции, не нужно писать во всех гемах все стандартные конвенции

[@zayko]

Если совпадает, значит все привилегии ему на стол

это далеко не всегда так. Проверка на Владение это лишь один из возможных критериев и его вполне себе можно не использовать в ряде систем.

за кадром осталось, кто отвечает за обновление поля USER_ID заданного объекта

Стандартный подход организации связи владелец-объект в рельсе: User has_many Pages + Page belongs_to User. За этот и другие виды связей отвечает разработчик.

проверяться могут отдельные поля, группы полей

если я правильно вас понимаю и вам интересна интергация со strong_parameters или нужен контроль отображения полей в форме — то это тоже довольно легко реализовать.

[@GearHead]

Меня не устраивает «программистский подход» решения задачи

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

[@zayko]

а потом для изменения работы политик доступа (уже существующей и функционирующей системы) необходимо пригласить программиста

вы процитировали текст вне контекста. Я говорил о политиках доступа, определяемых ACL. Я нигде не заявлял, что система все сделает сама. Ответ на ваш вопрос простой — никак. Ваша система может обладать множеством критериев доступности операции, которые не укладываются в перечень 10 фундаментальных критериев персонального и группового доступа.

[@foxmuldercp]

В одном из своих проектов я ACL делал приблизительно так же, как и Вы
Таблица sql:
user_id, http_method, route_url

Модель отдалённо похожа на unix'овую.
Соответственно, юзер может GET url, может POST, ну или PATCH, к примеру.
нулевым юзером у меня шёл авторизированный demo юзер, которому не давались get/post разрешения на mission-critical страницы, вроде статуса сервера или получить профиль конкретного пользователя, при этом с гибкой возможностью смотреть допустим список пользователей, но без права отправки им сообщения.