Как стать автором
Обновить

Комментарии 14

Илья, спасибо за гем, для меня он оказался очень полезным.
К сожалению не обнаружил хотя бы минимального сравнения с CanCan, раз последний — стандарт де-факто. Самого ожидает окунание в мир гемов авторизации, поэтому искал этот момент.
p.s.
Стиль изложения выдаёт в авторе продукт высшей школы (неоконченая аспирантура?): огромная вводная часть о мироощущении и гармонии вселенной, и только к середине статьи начинается бодрое деловое изложение. Текст для технического ресурса типа хабра надо сушить со сташной силой, благо сам ruby — образчик лаконичности. Прошу прощения за критику, но сам такой.
неоконченая аспирантура?
o_O Ну да, я не защищался, за отсутствием какого-либо влияния на мое будущее. Но сделать такой вывод из статьи — это сильно :D
не обнаружил хотя бы минимального сравнения с CanCan

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

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

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

2) Доступность операции. Здесь тоже понятно. Стандартный Access List с набором возможных действий и ролями, которые данные действия могут выполнять. Только у нас более наворочено, т.к. проверяться могут отдельные поля, группы полей и т.д.
1) гем только проверяет, странно ожидать что гем будет отвечать за консистентность
я догадываюсь. Просто для новичков это может быть совсем неочевидно, и об этом надо писать.
Это конвенции, не нужно писать во всех гемах все стандартные конвенции
Если совпадает, значит все привилегии ему на стол
это далеко не всегда так. Проверка на Владение это лишь один из возможных критериев и его вполне себе можно не использовать в ряде систем.
за кадром осталось, кто отвечает за обновление поля USER_ID заданного объекта
Стандартный подход организации связи владелец-объект в рельсе: User has_many Pages + Page belongs_to User. За этот и другие виды связей отвечает разработчик.
проверяться могут отдельные поля, группы полей
если я правильно вас понимаю и вам интересна интергация со strong_parameters или нужен контроль отображения полей в форме — то это тоже довольно легко реализовать.
Меня не устраивает «программистский подход» решения задачи

Объясните, как с помощью пользовательского подхода определить простое правило: комментарии могут писать только пользователи с положительным рейтингом.
а потом для изменения работы политик доступа (уже существующей и функционирующей системы) необходимо пригласить программиста
вы процитировали текст вне контекста. Я говорил о политиках доступа, определяемых ACL. Я нигде не заявлял, что система все сделает сама. Ответ на ваш вопрос простой — никак. Ваша система может обладать множеством критериев доступности операции, которые не укладываются в перечень 10 фундаментальных критериев персонального и группового доступа.
В одном из своих проектов я ACL делал приблизительно так же, как и Вы
Таблица sql:
user_id, http_method, route_url

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