Меню
Что нового?

Права пользователей/модераторов

Вурдалак

Продвинутый новичок
Права пользователей/модераторов

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

Есть список групп, у каждой из которых есть список прав, тупо забитых в bitfield (tinyblob). При запросе групп их права «складываются» через «|». В коде выполняется проверка вроде такой:
PHP: 
if( $user->permissionsBitfield & BAN_PERMISSION ) {
    // User has the banhammer
}
Это простое решение позволяет создавать/удалять группы и редактировать права из панели администратора, без копания в коде. Да и достаточно нересурсоёмкое.

Какую схему применяете вы?
 
Ragazzo

Ragazzo

TDD interested
Отдельно таблица с правами и группами, а у пользователей/модераторов лишь признак принадлежности к группе , id типа int...не идеально но гибко...но щас рассматриваю другие системы разделения ролей
 
Духовность™

Духовность™

Продвинутый новичок
У таблице пользователей есть поле id_group - признак принадлежности к группе. http://keep4u.ru/full/69a8e04ba4de252b1f5168008ef1d7df.html

Группы - делятся на 3 основные системные: гости, админы и пользователи + группы которые можно создать по желанию, например, группа "демо" с ограниченными возможностями. http://keep4u.ru/full/f9562640b715fbb7c77219c7662a60ed.html

Каждая группа имеет разрешение (1) или отсутствие разрешения (0) на контроллер. http://keep4u.ru/full/8ef50f38f387bb2521e6db05ee102207.html

Каждый контроллер в системе, в котором нужно делать проверку прав, имеет свой ID, поэтому все такие контроллеры регистрируются в системе, что очень не удобно и потребовало написания соответствующего интерфейса. http://keep4u.ru/full/b392b7b087e88abc1f8f3131e415bf0e.html



Вурдалак я не понял ничего. Что значит "список прав, тупо забитых в bitfield"? Как это выглядит? Как права определяют, куда можно пользователю, а куда нельзя?
 
korchasa

korchasa

LIMB infected
Вурдалак
Мы по привычке используем очень гибкую, но вполне стандартную acl. Роли, ресурсы, привилегии и все такое.

triumvirat
ИМХО, использовать в качестве ресурсов контроллеры и отказываться от привилегий, как то не гибко, не? Не проще тогда не вносить лишних знаний о контроллерах в интерфейс и не фильтровать просто по маске url'а?
 
Духовность™

Духовность™

Продвинутый новичок
korchasa
а как по другому?
есть группа, для неё должны быть назначены права, т.е. определения, что может эта группа, а что нет. Как это иначе то сделать, если не привязываться к контроллерам?
 

Вурдалак

Продвинутый новичок
korchasa, смотрел в ZF подобное. Я не всегда могу выделить объект, к которому требуется проверить доступ. Например, модератор может иметь право забанить пользователя, одновременно с этим удалив все его сообщения, поставив рядом со скором бана галку. А может и не иметь права удалять сообщения. Тогда эта галка отображаться не должна и соответствующий код удаления тоже не должен работать.
Но больше меня интересует как это работает в реальном коде, как ACL хранится в БД.

-~{}~ 28.09.10 10:27:

triumvirat, хранится набор установленных флагов (битов). Я проверяю в нужном месте, доступном только избранным, установлен ли флаг. Если установлен — пользователь имеет доступ, нет — значит нет.
 
zerkms

zerkms

TDD infected
Команда форума
Вурдалак
ну так добавь тогда привилегию "удалять все комменты" рядом с привилегией "банить" на ресурс "пользователь".
 
korchasa

korchasa

LIMB infected
triumvirat
По сути вы так и сделали, введя id-контроллера, аналог ресурса(или привилегии, зависит от реализации), в стандартных acl. Но в шаблонах то чтобы вывести ссылку тоже надо проверить права? Проверка id-контроллера? Шаблоны знают о контроллерах? Разница только в терминологии.
 
zerkms

zerkms

TDD infected
Команда форума
Роли (id, name)
Ресурсы (id, name)
ACL (id, role_id, resource_id, permission, permission_value)

При желании можно permission также выделить в отдельную таблу.

Решение в лоб :)
 
korchasa

korchasa

LIMB infected
Вурдалак
А в чем сложность? Ресурсы - словарь (или дерево, если есть наследование), роли - то же самое, привилегии - словарь(с ссылками на ресурсы), правила - список ссылок(роль и привилегия).
 
zerkms

zerkms

TDD infected
Команда форума
korchasa
В случае Zend'о-подобного ACL подобная структура, кстати, может внести небольшую головную боль в том плане, что правила необходимо применять в определённой очерёдности.
 

Вурдалак

Продвинутый новичок
Сложность в организации нескольких групп (ролей) для пользователя. Я не понимаю как эти права складывать.
 
korchasa

korchasa

LIMB infected
Вурдалак
А зачем складывать? Я, например, и пользователь, и админ. Надо проверить право модерировать статью? Проверили в роли пользователя, там нет. Проверили в роли модератора, там есть.

-~{}~ 28.09.10 11:15:

Автор оригинала: zerkms
korchasa
В случае Zend'о-подобного ACL подобная структура, кстати, может внести небольшую головную боль в том плане, что правила необходимо применять в определённой очерёдности.
Нажмите для раскрытия...
Проблема очередности да, есть. Из-за наследования. Но это терпимо, по опыту.

Это не Zend-подобный, а korchasa-подобный, я его 4 года назад впервые написал. И в limb'е он раньше zend'а появился :)
 

ХакИрФсимагущий

[засикречино]
А вот я шас разрабатыаю свою авторизацию и делаю так:
Определяю права пользователя - загружаю api для той категории, что нужно для обычных ничего не загружаю для забаненых самый минмум, для администраторов загружаю api на редактирывания и удаление и т.д. У меня даже есть возможность для разных групп сделать авторизацию разной сложности.

И шас все это собираюсь построить на ajax и js на пхп будет возможеность только подгрузки необходимого api дабы никто не взламал права).

имхо это очень гибко и рационально.
И еше один + не надо думать как выодить весь функционал через пхп в хтмл. у тебя есть аякс и ява скрипт который ты опять же подгружаешь в зависимости от прав. А также установка авторизации заключается толькко в добовлении 1 строчки в html код(даже не в php)

И естественно имею на каждую категорию отдельный фаил admin.php ban.php user.php moderatr.php в каждом из них сначало происходит авторизация, а потом доступ ко всем api.
 
Войдите или зарегистрируйтесь для ответа.
Сверху