Комментарии 14
НЛО прилетело и опубликовало эту надпись здесь
К сожалению не обнаружил хотя бы минимального сравнения с CanCan, раз последний — стандарт де-факто. Самого ожидает окунание в мир гемов авторизации, поэтому искал этот момент.
p.s.
Стиль изложения выдаёт в авторе продукт высшей школы (неоконченая аспирантура?): огромная вводная часть о мироощущении и гармонии вселенной, и только к середине статьи начинается бодрое деловое изложение. Текст для технического ресурса типа хабра надо сушить со сташной силой, благо сам ruby — образчик лаконичности. Прошу прощения за критику, но сам такой.
неоконченая аспирантура?o_O Ну да, я не защищался, за отсутствием какого-либо влияния на мое будущее. Но сделать такой вывод из статьи — это сильно :D
не обнаружил хотя бы минимального сравнения с CanCan
нет ни желания ни возможности в рамках статьи делать сравнения. Надо тогда сравнивать из несколькими другими решениями, т.к. к CanCan я лично не испытываю больших чувств, чем к другим гемам.
CanCan хорош для маленьких приложений, в больших же класс Ability жутко разрастается. Мы перешли на Pundit так как с ним можно работать гибче: в Policy-классе можно и скоупы строить, чтобы в контроллере показывать только доступные пользователю записи и каким-нибудь методом строить список полей для Strong Parameters, чтобы бесправный пользователь не мог случайно поменять то, что ему не положено в модели.
Пытался найти вменяемый перевод фразе «I second that!», но лучшее, к чему пришел — «полностью согласен». Когда в приложении пара сотен контроллеров, а пользователи разбиты на десяток разных групп (различия между которыми отличаются не более чем десятком контроллеров) — прагматик во мне испытывает невыносимую попоболь. В итоге сделали внутренний патч, позволяющий через LDAP группы присваивать пользователям более 1 ruleset'а.
Если будет время, и если автор не против, сделаю потом форк с habtm-ролями.
Если будет время, и если автор не против, сделаю потом форк с habtm-ролями.
Архитектура с этими двумя операциями вполне себе оправдана.
{quote}Владение — обычно мы хотим, что бы пользователь имел возможность исполнения важных операций только над теми объектами, которые ему принадлежат. Т.е. между пользователем и объектом есть некоторый признак принадлежности (владения). Что бы попасть в номер отеля вам нужно иметь ключ
Доступность операции — как правило определяется через ACL. Т.е. в неком хранилище есть информация о том, может ли данный пользователь в принципе исполнять некоторое действие. В деканате есть список студентов, которым можно сдавать экзамен {quote}
1) «Владение. „Как пример, в нашем проверенном годами фреймворке для классов тоже можно поставить галку “авторские права». Это значит, что при работе с объектом будет проверяться роль у пользователя «Автор», а у объекта соответствующее поле «Автор». Если совпадает, значит все привилегии ему на стол.
У вас я так понимаю то же самое. Правда за кадром осталось, кто отвечает за обновление поля USER_ID заданного объекта. Ваш гем или разработчик сам должен об это задуматься при действиях create.
2) Доступность операции. Здесь тоже понятно. Стандартный Access List с набором возможных действий и ролями, которые данные действия могут выполнять. Только у нас более наворочено, т.к. проверяться могут отдельные поля, группы полей и т.д.
{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 страницы, вроде статуса сервера или получить профиль конкретного пользователя, при этом с гибкой возможностью смотреть допустим список пользователей, но без права отправки им сообщения.
Таблица sql:
user_id, http_method, route_url
Модель отдалённо похожа на unix'овую.
Соответственно, юзер может GET url, может POST, ну или PATCH, к примеру.
нулевым юзером у меня шёл авторизированный demo юзер, которому не давались get/post разрешения на mission-critical страницы, вроде статуса сервера или получить профиль конкретного пользователя, при этом с гибкой возможностью смотреть допустим список пользователей, но без права отправки им сообщения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
TheRole 3. Авторизация для Ruby on Rails