divanikus
@divanikus

Модель безопасности веб-приложения?

В очередной раз захотелось сочинить что-нибудь эдакое, чтобы с одной стороны было гибко, а с другой относительно просто и не громоздко. Долго смотрел на механизмы ACL и им подобные, придумалось вот чего:

сделать для каждого объекта сайта наследуемые дискрипторы безопасности. Ну т.е. сам дискриптор это всего лишь набор «пользователь/группа -> привелегии». Вся загвоздка в наследовании и эффективном хранении и применении.


Ну т.е. вот возьмем пример, форум: у нас есть разделы, есть темы и есть посты. Стоит заметить, что это 3 разные сущности и напрямую наследовать привелегии над форумом на пост нельзя: понятно, что если у меня есть право редактировать форум, то у меня есть право редактировать пост, но наоборот неверно в общем случае. Тогда возникает вопрос — от чего наследовать права на еще не созданные сущности разных видов?


Плюсы тут я полагаю очевидны, ведь всякие фишки вроде премодерации (снимаем флаг чтение для юзеров) или куратор темы (добавляем конкретного пользователя с повышенными привелегиями для конкретной темы) вообще не требуют допилов, а просто возможны by design.


Минусы собственно в механизме наследования и эффективного применения дескрипторов: от кого наследовать вновь создаваемые сущности? С точки зрения эффективности — как делать выборки на основе дескрипторов, ну чтобы не вытаскивать лишние данные из базы с последующей дообработкой движком.


Реализацию планирую на Kohana3.


Кто-нибудь видел реализации подобных вещей? Под сабж или просто отдельно. Если есть сравнимая по гибкости альтернатива — подскажите пожалуйста куда копать?
  • Вопрос задан
  • 3238 просмотров
Пригласить эксперта
Ответы на вопрос 3
@werdender
Как-то все запутано, но надеюсь я правильно уловил смысл.
Если говорить в контексте KO3, то имхо, ее модуль Auth вполне расширяется в описанную сторону.
Там пользователю назначаются роли. Тогда группе пользователей с ролью login можно назначить определенные права в каждой модели.
Ответ написан
ProtoPlex
@ProtoPlex
Обычно ж вроже так:

Группы юзеров — для них базовые настройки безопасности
Юзеры — индивидуальные настройки, делегируемые с групп, юзер может состоять в нескольких группах

Дерево действий — иерархическая хрень, от корня к веткам свои галочки в безопасности. Новая ветка — наследование от корня и т.д.

Сделать быстро можно используя рекурсию и кеширование.
Ответ написан
MisterX
@MisterX
Можно попробовать акл вешать на роуты, имхо. У меня АКЛ, не на уровне записи, а на уровне доступа к роуту+екшн, и привязка идет к набору групп в которых состоит пользователь. Есть 3 дефолтовых группы, Админы, Авторизированые пользователи, Анонимные пользователи. Потом есть ф-я которая получает на вход роут, и список групп, и выдает есть доступ или нет. В общем вешать права на группу и только, т.к. если вешать и на группу и персонально на пользователя, много геморроя. И такой функционал, где нужно персонально пользователю надо что-то уникальное запретить, встречается крайне редко. А если и появится, сделать для него группу, и занести его туда.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы