Предлагаю на обсуждение следующую тему:
Разграничение прав доступа по следующей схеме:
В системе требуется следующее (абонентская система):
1. Назначение прав группе для выполнения некоторой функции
2. Назначение права отдельной персоне для выполнения некоторой функции
3. Возможность ограничить по времени доступ группе/персоне к исполнению некоторой функции
4. Возможность ограничить по количеству раз использования некоторой функции (например, пользователь не подтвердивший аккаунт через email, может отправить не более 5 сообщений внутри системы, просмотреть не более 20 топиков внутреннего форума, оставить в чате не более 100 сообщений, добавить не более 20 друзей)
5. Определить возможность выполнения некоторой функции к некоторому объекту на основании ресурсного владения - т.е. редактировать некоторый объект может не только владелец, но и назначенный модератором пользователь. Но редактировать данный пользователь сможет только назначенный объект (например какой-то блог) и только его. Кроме того, так же применить ограничение по времени и количеству раз доступа (например, назначенный пользователь отредактировал блог 10 раз - и хватит)
Вот задача стоит примерно следующим образом.
Кроме того, из данных требований нужно сделать универсальную систему сосредоточенную в одном модуле (плагине, геме, как душе будет угодно).
Интересно узнать ваш взгляд на поставленную задачу и услышать мнение о том, можно ли реализовать распространенными средствами. Возможно какие то варианты решения.
Спасибо! :)
ЗЫ:
Да! И сколько может стоить реализация такой штуки на ваш взгляд =)
Илья aka Зайко (aka Killich)
Тот самый учитель информатики >:0)
Зайко из-за того, что долго на аватаре стоял заяц Крош из Смешариков.
Илья aka Зайко
lockdown. это гем.
Правда, он слегка сыроват. Мне пришлось его в нескольких местах сразу monkey-патчить.
Ну, а особенности вашей системы придется писать самому (3,4,5 пункты).
Илья aka Зайко
Ммм даааа.
Вообще, судя по информации - задача не тривиальная. Ну что ж, тем интересней.
На самом деле я занимаюсь этим вопросом довольно давно. Только сейчас в голове созрела общая, и на мой взгляд, довольно красивая схема решения. Сейчас и занимаюсь тем, что ее реализую. Подумал, что возможно кто то сможет ткнуть меня носом в то, что все давно украдено до нас =)
А пока буду работать над своей реализацией.
Спасибо.
Илья aka Зайко (aka Killich)
Тот самый учитель информатики >:0)
Зайко из-за того, что долго на аватаре стоял заяц Крош из Смешариков.
Илья aka Зайко
Видел все описанные функции, но в разных плагинах.
Acl9 - справляется с ролями и объектными ролями.
authlogic - умеет генерировать токены для единоразового доступа, или для доступа только по rss. Наверняка можно допилить под нужды использовать по кол-ву раз и по времени.
Так что есть если не с чего начать то где посмотреть как реализовано.
По поводу пункта №4 - тут можно просто роль новую назначать после подтверждения адреса и набора нужного кол-ва сообщений, таким образом пересчёт прав будет производится реже - при отправке сообщения на форум или при валидации почты, а не каждый раз при попытке воспользоваться ограниченной функцией. Мне кажется будет несколько правильнее.
4. Возможность ограничить по количеству раз использования некоторой функции (например, пользователь не подтвердивший аккаунт через email, может отправить не более 5 сообщений внутри системы, просмотреть не более 20 топиков внутреннего форума, оставить в чате не более 100 сообщений, добавить не более 20 друзей)
На статусе пользователя тут замеса на самом деле мало.
Есть список материалов, пусть - 100 штук. При оплате можно посмотреть/скачать, ну пусть 10, например и только в отведенное время(месяц со дня оплаты).
Или в рамках конференции пользователям разрешено оставлять не более 20 сообщений (для ограничения флуда, что б каждый коммент и мысль на вес золота). А сама конференция в сети проходит с 10 по 15 число. Вот тебе и задачка - и по времени ограничить доступ к конференции, и по кол-ву сообщений.
А поскольку в системе уже заложено несколько подобных сущностей, то и нужно придумать что то универсальное, что б потом не зашиться, а использовать единообразный интерфейс.
И это все находится в постоянной динамике.
Да мало ли можно еще придумать примеров.
Сразу скажу - я не приверженец создания идеалов и мега ЦМС на все случае жизни. Я верю в узкоспециализированные системы под конкретные нужды.
Просто сформулированные заказчиком требования воплотились в такую формулировку и постановку задачи. Я б сам никогда наверное не додумался что могут быть такие требования, думал должно быть все проще - а жизнь оказалась как всегда интереснее =)
Илья aka Зайко (aka Killich)
Тот самый учитель информатики >:0)
Зайко из-за того, что долго на аватаре стоял заяц Крош из Смешариков.
Илья aka Зайко
Закончил писать код для озвученной в теме задачи.
Отработанной системы пока еще нет, но базовые интерфейсные функции уже готовы.
Тесты проверяющие функциональность сделаны и показывают, что реализация соответствует основной задумке.
Пока буду несколько дней отдыхать и писать доку к тому, что получилось.
Понял, что объяснить сделанное довольно трудно.
Если кому то будет интересно почитать - начало доки в следующем посте.
Надо будет кусок сдавать заказчику и хочется надеяться, что дальнейший разработчик поймет что было сделано и в случае чего сможет с этим работать.
Хотелось бы услышать отзывы о том, понятно ли из текста, то что мне удалось сделать и возможно у вас с лету будут замечания. ... вобщем - начало доки вот, а что будет - то и будет.
Илья aka Зайко (aka Killich)
Тот самый учитель информатики >:0)
Зайко из-за того, что долго на аватаре стоял заяц Крош из Смешариков.
Илья aka Зайко
acts_as_X
Простая абонентская система для web-сайта,
основанная на работе с обращениями к Hesh массивам
==========================================================================================================
Основные понятия:
==========================================================================================================
Политика (action)
Правило доступа к некоторой функции/действию (create, read, update, delete, show, hide и т.д.)
Имеет Булево значение true, false
Группа политик (section)
Набор логически связанных политик, предназначенных для работы с некоторым функционалом web-сайта (blog, forum, pages и т.д.)
Представляет собой Hesh массив из Политик и связанных с ними Булевыми зачениями
Роль (role)
Набор групп политик логически связанных со статусом пользователя в системе (guest, user, moderator, manager, developer, administrator)
Доступ (access)
Результат (Булево значение) обращения к некоторой политике и проверки ее на равенство значению true
Если политика имеет значение true - то доступ разрешен (возвращает true)
Блокировка (block)
Результат (Булево значение) обращения к некоторой политике и проверки ее на равенство значению false
Если политика имеет значение false - то доступ запрещен (ТОЖЕ!!! возвращает true)
Актуальность политики
Значимость политики доступа в настоящее время или по другому признаку
(счетчик исполнения политики доступа не превышает макс. установленного для него значения)
Исполнение политики доступа
Факт обращения к политике доступа
Ограничение исполнения политики доступа по времени (АКТУАЛЬНОСТЬ ПО ВРЕМЕНИ)
Установка начального (start_at) и конечного (finish_at) моментов времени, определяющих актуальность политики
Так, например, можно установить актуальность политики с 1 сентября по 7 сентября.
В этот период времени пользователь будет иметь доступ к исполнению некоторого действия.
8 сентября политики доступа теряет актуальность по времени.
В результате пользователь не может более исполнять некоторое действие.
Ограничение исполнения политики доступа по факту исполнения политики доступа (АКТУАЛЬНОСТЬ ПО СЧЕТЧИКУ)
Установка счетчика обращения (counter) к политике доступа и максимального значения (max_count) счетчика, которые определяют актуальность политики.
Так, например, можно установить максимальное значение счетчика на 10 (max_count= 10), а сам счетчик на 1 (counter= 1).
При каждом исполнении политики доступа счетчик увеличивается на 1 (counter= counter+1).
После 10 обращений к политике доступа политика теряет свою актуальность (counter =< max_count => false).
В результате пользователь не может более исполнять некоторое действие.
==========================================================================================================
acts_as_X реализует:
==========================================================================================================
> РОЛЕВОЕ РАЗГРАНИЧЕНИЕ ПОЛЬЗОВАТЕЛЕЙ НА САЙТЕ (ОСНОВОПОЛАГАЮЩАЯ РЕАЛИЗАЦИЯ БЕЗ УЧЕТА АКТУАЛЬНОСТИ ДОСТУПА ПО ВРЕМЕНИ И СЧЕТЧИКУ)
> РАЗГРАНИЧЕНИЕ ПО ПОЛИТИКАМ ДОСТУПА
== Группа пользователей:
- Назначение политики доступа некоторой группе пользователей (de facto: white_list of policies for group)
- (АКТУАЛЬНОСТЬ ДОСТУПА ПО ВРЕМЕНИ) Ограничение исполнения политики доступа некоторой группы пользователей по времени
- (АКТУАЛЬНОСТЬ ДОСТУПА ПО СЧЕТЧИКУ)Ограничение исполнения политики доступа некоторой группы пользователей по факту исполнения
- Назначение политики блокировки некоторой группе пользователей (de facto: black_list of policies for group)
- (АКТУАЛЬНОСТЬ БЛОКИРОВКИ ПО ВРЕМЕНИ) Ограничение исполнения политики блокировки некоторой группы пользователей по времени
- (АКТУАЛЬНОСТЬ БЛОКИРОВКИ ПО СЧЕТЧИКУ)Ограничение исполнения политики блокировки некоторой группы пользователей по факту исполнения
== Конкретный пользователь:
- Назначение политики доступа пользователю (de facto: white_list of policies for person)
- (АКТУАЛЬНОСТЬ ДОСТУПА ПО ВРЕМЕНИ) Ограничение исполнения политики доступа пользователя по времени
- (АКТУАЛЬНОСТЬ ДОСТУПА ПО СЧЕТЧИКУ) Ограничение исполнения политики доступа пользователя по факту исполнения
- Назначение политики блокировки пользователю (de facto: black_list of policies for person)
- (АКТУАЛЬНОСТЬ БЛОКИРОВКИ ПО ВРЕМЕНИ) Ограничение исполнения политики блокировки пользователя по времени
- (АКТУАЛЬНОСТЬ БЛОКИРОВКИ ПО СЧЕТЧИКУ)Ограничение исполнения политики блокировки пользователя по факту исполнения
> РАЗГРАНИЧЕНИЕ ПО РЕСУРСНОМУ ВЛАДЕНИЮ И ИСПОЛНЕНИЮ ДЕЙСТВИЙ НАД РЕСУРСОМ
== Группа пользователей:
- Назначение политики доступа некоторой группе пользователей для конкретного объекта (de facto: white_list of policies for resource for group)
- (АКТУАЛЬНОСТЬ ДОСТУПА ПО ВРЕМЕНИ) Ограничение исполнения политики доступа некоторой группы пользователей по времени для конкретного объекта
- (АКТУАЛЬНОСТЬ ДОСТУПА ПО СЧЕТЧИКУ) Ограничение исполнения политики доступа некоторой группы пользователей по факту исполнения для конкретного объекта
- Назначение политики блокировки некоторой группе пользователей (de facto: black_list of policies for resource for group)
- (АКТУАЛЬНОСТЬ БЛОКИРОВКИ ПО ВРЕМЕНИ) Ограничение исполнения политики блокировки некоторой группы пользователей по времени для конкретного объекта
- (АКТУАЛЬНОСТЬ БЛОКИРОВКИ ПО СЧЕТЧИКУ) Ограничение исполнения политики блокировки некоторой группы пользователей по факту исполнения для конкретного объекта
== Конкретный пользователь:
- Назначение политики доступа пользователю (de facto: white_list of policies for resource for person)
- (АКТУАЛЬНОСТЬ ДОСТУПА ПО ВРЕМЕНИ) Ограничение исполнения политики доступа пользователя по времени для конкретного объекта
- (АКТУАЛЬНОСТЬ ДОСТУПА ПО СЧЕТЧИКУ) Ограничение исполнения политики доступа пользователя по факту исполнения для конкретного объекта
- Назначение политики блокировки пользователю (de facto: black_list of policies for resource for person)
- (АКТУАЛЬНОСТЬ БЛОКИРОВКИ ПО ВРЕМЕНИ) Ограничение исполнения политики блокировки пользователя по времени для конкретного объекта
- (АКТУАЛЬНОСТЬ БЛОКИРОВКИ ПО СЧЕТЧИКУ) Ограничение исполнения политики блокировки пользователя по факту исполнения для конкретного объекта
Илья aka Зайко (aka Killich)
Тот самый учитель информатики >:0)
Зайко из-за того, что долго на аватаре стоял заяц Крош из Смешариков.
