Правильно ли я подошел к теме разграничения прав?

[Духовность™]

В общем, назрел рефакторинг и я хочу спросить, правильно ли я подошел к теме разделения прав доступа, ибо когда я это все писал, мозг был не включен и как результат - много говнокода...

На текущий момент я делаю так (утрированно): если на какой-то action, например "редактирование новостей", нужно поставить проверку прав доступа, то в базе создается запись "NEWS_EDIT". Это просто уникальный строковой идентификатор, имеющий свой числовой ID.

Когда создается группа пользователей, то в таблицу связей, состоящую из столбцов ID_GROUP, ID_ACTION, ACCESS пишутся соответствующие значение. ACCESS, если кто не понял - 1 или 0 (право), а ID_ACTION - ID экшена, т.е. записи типа "NEWS_EDIT".

В коде, когда запрашивается скрипт редактирования новостей, просто делается проверка:

if ($this->checkAccess($user->getGroup(), "NEWS_EDIT")) ....

которая смотрит, разрешен ли доступ группе $user->getGroup() на action "NEWS_EDIT"

Суть моего вопроса в том, правильно ли я делаю, что привязываюсь в коде программы к строковому идентификатору "NEWS_EDIT"?

 

[флоппик]

Суть в том, что к чему-нибудь тебе привязываться все равно придется, а числовой, или строковый идентификатор... ну, сделай define('NEWS_EDIT', 122); и храни цифирку. В любом случае, где-то, когда-то, тебе надо будет указать этот идентификатор непосредственно в коде.

 

[флоппик]

А если брать с точки зрения теории разграничения прав доступа вообще, надо почитать про ACL.
Даже могу подарить тебе кусок из своего старого ТЗ:

3.1.15. Управление пользователями и ролями
Для управления правами доступа к различным функциям и хранимым данным в ПО, используется система ролей.
Роли, возможно назначать группам пользователей, добавление пользователя в группу автоматически повлечет присвоение ему всех ролей группы. Пользователь может входить в несколько групп одновременно.
Роли, выданные персонально пользователю, имеют больший приоритет, чем групповые роли. Так, возможно дать разрешение на просмотр или редактирование документа, к которому запрещен доступ у всей группы.
В случае наличия противоречащих ролей в разных группах, в которые входит пользователь, приоритет имеет запрещающая групповая роль, либо персональная разрешающая. Отсутствие явного указания роли предполагает запрещающую роль.
Для определения права доступа пользователя к документу происходит последовательная сверка ролей для документа, и при необходимости для каждого уровня вложенности структуры документов.
Важно: Пользователь, обладающий административной ролью «Назначение ролей пользователям» может получить любую разрешающую роль.

3.1.15.1. Управляющие доступом к функциям программы.
Роли, управляющие доступом к функциям программы, определяют возможность пользователя создавать новые документы, управлять чужими блокировками документа, управлять доступом других пользователей, назначать им роли, вносить и удалять их из групп.

3.1.15.2. Управляющие доступом к разделам.
Роли, управляющие доступом к разделам, определяют возможность читать и редактировать документы соответствующего раздела.

3.1.15.3. Управляющие доступом к документам.
Роли, управляющие доступом к документам, имеют больший приоритет, чем роль доступа к разделу, так, можно запретить пользователю просматривать все документы раздела, кроме тех, на которые выдано разрешительная роль, или наоборот.