В этой статье мы пройдём с вами полный цикл от идеи, проектирования БД, написания PHP-Кода, и завершающей оптимизации. Постараюсь рассказать обо всем, как можно проще. Использовать для примеров буду PHP и Mysql. Заодно потренирую новичков :).
В этой статье я коснусь вопросов:
1. Идея ACL
2. Проектирование БД
3. Нормализация БД
4. Рефакторинг кода
5. Оптимизация рабочего кода
Статья является ответом на Бинарное распределение прав доступа в CMS. Пока автором пишется практическая часть, я хочу предоставить мой вариант, который я использую довольно давно.
То, что я сейчас расскажу, похоже на ACL.
Права доступа принадлежат ко всем объектам, к которым необходимо их применять.
Если рассматривать пример простой страницы новостей (которую мы с вами здесь напишем), то права доступа должны иметь:
1) Основная страница новостей — глобальные права доступа, означающие «создание новой новости», «модерирование новостей», «просмотр самой страницы».
2) Каждая новость — возможности «редактировать автором новости» или «не оставлять комментарии».
Система прав доступа состоит из:
{Group}+{Actions} или {Group}-{Actions}
Group — это набор имен, которые из себя представляют:
1) Права конкретного пользователя (например 'User1', 'User2'...). Например используется для личных сообщений, к которым этот пользователь имеет доступ или для допуска редактирования только его сообщений на сайте.
2) Группы приватных страниц (или групп пользователей), к которым необходимо дать права на определенные действия. (например, администраторами, супермодераторами и др.)
3) Дополнительные свойства. (Например, флаг — переключатель режимов)
Action — набор действий, которые пользователи с имеющимся {Group} могут делать. В нашей системе новостей можно использовать:
N — добавлять новую тему
D — удалять тему
E — редактировать тему
V — видеть тему
C — оставлять комментарий
B — удалять комментарий
± означает давать пользователю с такими правами или не давать (приоритетно) доступ к действию. Например: Users+VC, Users-C = Users+V.
Теперь рассмотрим пример прав доступа, для простого сайта новостей:
Объект MainNewsPage:
Users+VC, Moderator+NEDB, Admin+NEDB
Объект NewsMessage:
User1+ED (в принципе не нужно, если добавлять могут только модераторы)
Users-C (можно использовать, если нет желания оставлять комментарии)
Объект NewsComment:
User2+B (а здесь необходимо, так как комментарий может оставлять любой пользователь, но не все могут удалять их)
Для начала, определим Базы данных, для работы с правами объектов.
Так как у нас получается список нескольких прав, то можно начать с такой БД:
RightsID — идентификатор списка прав.
Group — название группы.
Sign — знак группы.
Action — название действия.
Пример1 (права для MainNewsPage):
Пример2 (права для NewsMessage):
Теперь, если мы запросим SELECT * FROM `rights_action` WHERE `RightsID`=100, то получим все права, которые принадлежат необходимому нам объекту.
У пользователя, который будет просматривать нашу страницу, должны иметься права, которыми он владеет. Исходя из них, мы сможем знать, имеет ли пользователь право на действие.
Например: User2, Users, Moderator.
Для этого определим таблицу прав:
RightsID — идентификатор списка прав пользователя.
Group — название группы, в которой пользователь состоит.
Пример:
Теперь приведем обе наши таблицы к нормальной форме. (wiki)
В результате ID ключи отсеются, и мы получим 3 таблицы:
rights_action — права объекта
RightsID: integer (pk) — идентификатор списка прав.
GroupID: integer (pk) — название группы.
Sign: tinyint (1) — знак группы.
Action: enum (pk) — название действия.
rights_group — права пользователя
RightsID: integer (pk) — идентификатор списка прав пользователя.
GroupID: integer (pk) — идентификатор группы, в которой пользователь состоит.
rights_names — названия групп
GroupID: integer (pk) — идентификатор группы.
name — название группы.
Primary key 'ID' мы заменили на другие ключи, состоящие в некоторых случаях из нескольких полей таблицы.
Знак группы теперь 0 (+) или 1 (-), потому что так нам будет проще к ним обращаться.
Идентификатор GroupID прямиком указывает на название в rights_names.
На самом деле таблица rights_names является в нашем случае аппендиксом, который не будет использоваться для выявления прав на необходимое действие. Эта таблица теперь служит лишь для «Очеловечивания» результатов.
Пример, что у нас получилось:
Стало менее наглядно — для человека. Компьютеру, который оперирует числами, стало намного проще обращаться с таблицами.
Теперь мы можем добавить права любому объекту в таблице на любое действие. Действия теперь записываются в таблицу в виде ENUM (поле 'action'), что упрощает понимание и разработку проектов. Само действие как string и может называться, как угодно.
`rights_group` должна быть привязана к пользователям и говорит о тех правах, которыми пользователь обладает.
`rights_action` должна быть привязана к объектам и говорит, с каким правами, какие действия пользователь может выполнять.
Например (для нашего сайта новостей):
А сейчас мы посмотрим, что необходимо, чтобы эти таблицы собрать воедино и произвести необходимую нам выборку результатов.
Алгоритм наших действий при проверке возможности действия:
1) Берем из БД выборку прав по необходимому объекту (объектам). (100: Users+VC, Moderator+NEDB, Admin+NEDB)
2) Выбираем необходимые нам действия (action). (V: Users+V)
3) Сравниваем права доступа пользователя и нашей выборки. (Users, User1 <=> Users+)
4) Если результатов нет, тогда возвращаем false.
5) Если результаты есть, но состоят из минусов, возвращаем false. Иначе возвращаем true.
Ещё один момент, который стоит заметить: права доступа от parent (страницы новостей) переходят к child (в данном случае, к сообщению). То есть, если указать на странице +'message_view', то все сообщения автоматически будут с такими правами (чтения). Это обстоятельство мы будем использовать и проверять в пункте 1 нашего алгоритма.
Перейдем к реализации:
На самом деле нам сейчас не требуется PHP для того, чтобы сделать правильную выборку. Всё сделаем на mysql.
Пункт 1.
В нашем случае необходимо считать данные `rightsID` из нескольких объектов и затем выбрать их из нашей таблицы.
Несколько объектов, потому что у нас будут права на страницу и права на отдельных сообщений на странице. Права обоих будут дополнять друг друга. (child дополнять parent)
Например, права сообщения на странице:
SELECT * FROM `rights_action` WHERE `RightsID`=100 or `RightsID`=101 , где
100 — ID прав страницы
101 — ID прав сообщения на странице
Для того, чтобы было проще общаться на PHP, немного оптимизируем синтаксис:
SELECT * FROM `rights_action` WHERE `RightsID` IN (100, 101)
Пункт 2.
С выбором необходимого нам действия, тоже всё просто:
SELECT * FROM `rights_action` WHERE `action`= 'message_view'
Пункт 3.
А вот здесь придется объединить несколько SELECTов. Сначала выбираем права доступа пользователя, а затем сравниваем их с необходимыми нам. Если объединить эти действия в одно, получится:
SELECT * FROM `rights_action` WHERE `GroupID` IN (SELECT `GroupID` FROM `rights_group` WHERE `RightsID` = 1)
Пункт 1-3.
Теперь всё вместе одним сложным запросом:
Пункт 1-5.
Вставим это в PHP реализацию и заодно добавим проверку:
Что нам необходимо?
Разработаем пример работы с нашим классом.
1) Во-первых, необходимо указать права пользователя, с правами которого нам надо работать. А сам класс необходимо привязать к конкретному пользователю.
2) Добавление в класс child-прав объектов с дополнением свойств.
3) Проверка доступа по различным действиям (action).
Замечания и мысли:
Права пользователя можно указать при создании класса в __construct.
При добавлении новых свойств, чтобы не терялись свойства в классе, необходимо будет делать новый класс (клонировать старый с добавлением свойств).
Давайте попробуем это всё реализовать:
Рассмотрим добавление права объекта для проверки:
Теперь перепишем нашу функцию check, введя её в класс, и посмотрим что получилось:
Сейчас этот класс можно использовать вот так:
$MainPage — структура страницы, который смотрит пользователь.
$MainPage->Messages — массив сообщений, которые выводятся на странице.
Структуры, предварительно, были считаны из БД.
Качеством и функциональностью библиотеки мы с вами довольны, но возникает вопрос производительности.
Первое, что бросается в глаза — это при каждой проверке с новым 'action', происходит не хилый SQL запрос. Давайте попробуем это исправить.
Для начала посмотрим, что от запроса к запросу не меняется и оптимизируем это.
Во-первых, каждый раз происходит запрос SELECT `GroupID` FROM `rights_group` WHERE `RightsID` = .... Давайте с него и начнем.
При объявлении UserRights проведем этот запрос один раз, а результат уже будем вставлять в наш SQL-запрос.
Уже стало легче, но все равно происходит поиск по всей БД каждый запрос. Как нам от этого можно избавиться? Вероятнее всего, создать предварительный результат, зависящий только от action — потому что выборка `RightsID` и `GroupID` остается неизменной.
Когда добавляется группа объектов, считываем все результаты из БД в массив, который будет зависеть лишь от значений 'action'.
Далее, уже перебором по каждому 'action' в массиве, ищем необходимый элемент. При этом запросов в БД больше нет — до следующего объекта с новыми правами.
В результате оптимизации, наш класс будет выглядеть вот так:
Да, можно.
1) Если учитывать, например пустые группы прав у сообщений (child), которые не поменяют нашу уже используемую временную таблицу. В этом случае мы можем использовать её, не создавая заново. А для проверки, нам необходимо добавить лишь ещё один SELECT count(*) FROM `action_rights` WHERE `GroupID` =…, который пройдётся по индексу и вернет результат.
2) Правильно расставить индексы в таблицах `action_rights` и `group_rights`.
Тут я не уверен. Эксперты меня надеюсь, поправят. Лично сделал PK — 'rightsID', 'action', 'groupID', INDEX — 'groupID', 'rightsID'
3) После создания Temporary Table, добавлять в неё индекс по 'action': ALTER TABLE `{$this->temptable}` ADD INDEX ( `action` ).
Правда я не уверен, что этот способ тоже действенен. Эксперты, посвятите пожалуйста. :)
4) Использовать кеш. Но это уже другая история :)
Я думаю, что уже достаточно на сегодня кода. Вот как это работает:
работающий пример — извиняюсь за не наглядность.
test.php (рабочий пример) — здесь используются мои библиотеки, которые работают с SQL БД, не удивляйтесь. Уверен, что разберетесь.
rights.php — наша библиотека.
Любые новые действия, которые вы будете использовать в вашем проекте добавляются в 'action' ENUM.
Если вы не хотите быть привязанным к конкретным действиям и добавлять их в реальном времени, то стоит заменить 'action' ENUM на integer и создать ещё одну таблицу соответствий actionID с action_name. (как мы сделали это с названиями Групп)
Update: Появилось продолжение: Оптимизации системы разделения прав доступа в веб-приложении
В этой статье я коснусь вопросов:
1. Идея ACL
2. Проектирование БД
3. Нормализация БД
4. Рефакторинг кода
5. Оптимизация рабочего кода
Статья является ответом на Бинарное распределение прав доступа в CMS. Пока автором пишется практическая часть, я хочу предоставить мой вариант, который я использую довольно давно.
То, что я сейчас расскажу, похоже на ACL.
Упрощенное описание идеи
Права доступа принадлежат ко всем объектам, к которым необходимо их применять.
Если рассматривать пример простой страницы новостей (которую мы с вами здесь напишем), то права доступа должны иметь:
1) Основная страница новостей — глобальные права доступа, означающие «создание новой новости», «модерирование новостей», «просмотр самой страницы».
2) Каждая новость — возможности «редактировать автором новости» или «не оставлять комментарии».
Система прав доступа состоит из:
{Group}+{Actions} или {Group}-{Actions}
Group — это набор имен, которые из себя представляют:
1) Права конкретного пользователя (например 'User1', 'User2'...). Например используется для личных сообщений, к которым этот пользователь имеет доступ или для допуска редактирования только его сообщений на сайте.
2) Группы приватных страниц (или групп пользователей), к которым необходимо дать права на определенные действия. (например, администраторами, супермодераторами и др.)
3) Дополнительные свойства. (Например, флаг — переключатель режимов)
Action — набор действий, которые пользователи с имеющимся {Group} могут делать. В нашей системе новостей можно использовать:
N — добавлять новую тему
D — удалять тему
E — редактировать тему
V — видеть тему
C — оставлять комментарий
B — удалять комментарий
± означает давать пользователю с такими правами или не давать (приоритетно) доступ к действию. Например: Users+VC, Users-C = Users+V.
Теперь рассмотрим пример прав доступа, для простого сайта новостей:
Объект MainNewsPage:
Users+VC, Moderator+NEDB, Admin+NEDB
Объект NewsMessage:
User1+ED (в принципе не нужно, если добавлять могут только модераторы)
Users-C (можно использовать, если нет желания оставлять комментарии)
Объект NewsComment:
User2+B (а здесь необходимо, так как комментарий может оставлять любой пользователь, но не все могут удалять их)
Упростим систему, для понимания идеи компьютером
Для начала, определим Базы данных, для работы с правами объектов.
Так как у нас получается список нескольких прав, то можно начать с такой БД:
RightsID — идентификатор списка прав.
Group — название группы.
Sign — знак группы.
Action — название действия.
Пример1 (права для MainNewsPage):
| ID | RightsID | Group | Sign | Action |
|---|---|---|---|---|
| 1 | 100 | Users | + | V |
| 2 | 100 | Users | + | C |
| 3 | 100 | Moderator | + | N |
| 4 | 100 | Moderator | + | E |
| 5 | 100 | Moderator | + | D |
| 6 | 100 | Moderator | + | B |
| 7 | 100 | Admin | + | N |
| 8 | 100 | Admin | + | E |
| 9 | 100 | Admin | + | D |
| 10 | 100 | Admin | + | B |
Пример2 (права для NewsMessage):
| ID | RightsID | Group | Sign | Action |
|---|---|---|---|---|
| 11 | 101 | User1 | + | D |
| 12 | 101 | User1 | + | E |
| 13 | 101 | Users | - | C |
Теперь, если мы запросим SELECT * FROM `rights_action` WHERE `RightsID`=100, то получим все права, которые принадлежат необходимому нам объекту.
Нормализация таблиц. Добавляем права пользователя.
У пользователя, который будет просматривать нашу страницу, должны иметься права, которыми он владеет. Исходя из них, мы сможем знать, имеет ли пользователь право на действие.
Например: User2, Users, Moderator.
Для этого определим таблицу прав:
RightsID — идентификатор списка прав пользователя.
Group — название группы, в которой пользователь состоит.
Пример:
| ID | RightsID | Group |
|---|---|---|
| 1 | 10 | User1 |
| 2 | 10 | Users |
| 3 | 10 | Moderator |
В результате ID ключи отсеются, и мы получим 3 таблицы:
rights_action — права объекта
RightsID: integer (pk) — идентификатор списка прав.
GroupID: integer (pk) — название группы.
Sign: tinyint (1) — знак группы.
Action: enum (pk) — название действия.
rights_group — права пользователя
RightsID: integer (pk) — идентификатор списка прав пользователя.
GroupID: integer (pk) — идентификатор группы, в которой пользователь состоит.
rights_names — названия групп
GroupID: integer (pk) — идентификатор группы.
name — название группы.
Primary key 'ID' мы заменили на другие ключи, состоящие в некоторых случаях из нескольких полей таблицы.
Знак группы теперь 0 (+) или 1 (-), потому что так нам будет проще к ним обращаться.
Идентификатор GroupID прямиком указывает на название в rights_names.
На самом деле таблица rights_names является в нашем случае аппендиксом, который не будет использоваться для выявления прав на необходимое действие. Эта таблица теперь служит лишь для «Очеловечивания» результатов.
Пример, что у нас получилось:
| rights_name | |||
|---|---|---|---|
| GroupID | name | ||
| 10 | Users | ||
| 11 | Moderator | ||
| 12 | Admin | ||
| 1001 | User1 | ||
| 1002 | User2 | ||
| 1003 | User3 | ||
| rights_group | |||
| RightsID | GroupID | ||
| 1 | 1001 | ||
| 1 | 10 | ||
| 1 | 11 | ||
| rights_action | |||
| RightsID | GroupID | Sign | Action |
| 100 | 10 | 0 | message_view |
| 100 | 10 | 0 | comment_create |
| 100 | 11 | 0 | message_create |
| 100 | 11 | 0 | message_edit |
| 100 | 11 | 0 | message_delete |
| 100 | 11 | 0 | comment_delete |
| 100 | 12 | 0 | message_create |
| 100 | 12 | 0 | message_edit |
| 100 | 12 | 0 | message_delete |
| 100 | 12 | 0 | comment_delete |
| 101 | 1001 | 0 | message_edit |
| 101 | 1001 | 0 | message_delete |
| 101 | 10 | 1 | comment_create |
Теперь мы можем добавить права любому объекту в таблице на любое действие. Действия теперь записываются в таблицу в виде ENUM (поле 'action'), что упрощает понимание и разработку проектов. Само действие как string и может называться, как угодно.
`rights_group` должна быть привязана к пользователям и говорит о тех правах, которыми пользователь обладает.
`rights_action` должна быть привязана к объектам и говорит, с каким правами, какие действия пользователь может выполнять.
Например (для нашего сайта новостей):
| news_page (параметры основной страница с новостями) | ||||
|---|---|---|---|---|
| PageID | RightsID | Name | ||
| 1 | 100 | Страница новостей | ||
| news_message (сообщения на странице новостей) | ||||
| MsgID | PageID | RightsID | Header | Message |
| 1 | 1 | 101 | Ура, мы на главной!!! | Но это только начало, дальше, когда мы ближе подберемся к администрации хабра... |
| 2 | 1 | 101 | Новости последней недели | Не смотря на наше стройное шествие по главной, похоже планы обломались... |
Разработка библиотеки работы с правами доступа
А сейчас мы посмотрим, что необходимо, чтобы эти таблицы собрать воедино и произвести необходимую нам выборку результатов.
Алгоритм наших действий при проверке возможности действия:
1) Берем из БД выборку прав по необходимому объекту (объектам). (100: Users+VC, Moderator+NEDB, Admin+NEDB)
2) Выбираем необходимые нам действия (action). (V: Users+V)
3) Сравниваем права доступа пользователя и нашей выборки. (Users, User1 <=> Users+)
4) Если результатов нет, тогда возвращаем false.
5) Если результаты есть, но состоят из минусов, возвращаем false. Иначе возвращаем true.
Ещё один момент, который стоит заметить: права доступа от parent (страницы новостей) переходят к child (в данном случае, к сообщению). То есть, если указать на странице +'message_view', то все сообщения автоматически будут с такими правами (чтения). Это обстоятельство мы будем использовать и проверять в пункте 1 нашего алгоритма.
Перейдем к реализации:
На самом деле нам сейчас не требуется PHP для того, чтобы сделать правильную выборку. Всё сделаем на mysql.
Пункт 1.
В нашем случае необходимо считать данные `rightsID` из нескольких объектов и затем выбрать их из нашей таблицы.
Несколько объектов, потому что у нас будут права на страницу и права на отдельных сообщений на странице. Права обоих будут дополнять друг друга. (child дополнять parent)
Например, права сообщения на странице:
SELECT * FROM `rights_action` WHERE `RightsID`=100 or `RightsID`=101 , где
100 — ID прав страницы
101 — ID прав сообщения на странице
Для того, чтобы было проще общаться на PHP, немного оптимизируем синтаксис:
SELECT * FROM `rights_action` WHERE `RightsID` IN (100, 101)
Пункт 2.
С выбором необходимого нам действия, тоже всё просто:
SELECT * FROM `rights_action` WHERE `action`= 'message_view'
Пункт 3.
А вот здесь придется объединить несколько SELECTов. Сначала выбираем права доступа пользователя, а затем сравниваем их с необходимыми нам. Если объединить эти действия в одно, получится:
SELECT * FROM `rights_action` WHERE `GroupID` IN (SELECT `GroupID` FROM `rights_group` WHERE `RightsID` = 1)
Пункт 1-3.
Теперь всё вместе одним сложным запросом:
SELECT * FROM `rights_action` WHERE `RightsID` IN (100, 101) AND `action`= 'message_view' AND `GroupID` IN (SELECT `GroupID` FROM `rights_group` WHERE `RightsID` = 1)этот пример, берет права пользователя №1, права объектов №100 и №101, действие 'просмотр сообщений' (message_view) и выдаёт результат (знаки + и -).
Пункт 1-5.
Вставим это в PHP реализацию и заодно добавим проверку:
function check(/*array(int,int,...)*/ $obj_rights, /*integer*/ $user_rightsID, /*string*/ $action){
$result = mysql_query("SELECT * FROM `rights_action` WHERE `RightsID` IN (". implode(",",$obj_rights) .") AND `action`= '$action' AND `GroupID` IN (SELECT `GroupID` FROM `rights_group` WHERE `RightsID` = $user_rightsID)");
if (!$result)
return false;
$tmp=array();
while ($t = mysql_fetch_assoc($result)){
//В каждую из найденных групп (Users, User1, Moderator) пользователей
//заполняем + (0) или - (1) (с приоритетом).
if (!isset($tmp[$t['groupID']]))
$tmp[$t['groupID']] = $t['sign'];
else
$tmp[$t['groupID']] |= $t['sign'];
}
mysql_free_result($result);
if ($tmp)
//Если нашли + в любой из групп, возвращаем true. Иначе false.
return (array_search(0, $tmp) !== FALSE);
//Не нашли ни одного результата $tmp == false
return false;
}
* This source code was highlighted with Source Code Highlighter.Создаём класс работы с правами доступа
Что нам необходимо?
Разработаем пример работы с нашим классом.
1) Во-первых, необходимо указать права пользователя, с правами которого нам надо работать. А сам класс необходимо привязать к конкретному пользователю.
2) Добавление в класс child-прав объектов с дополнением свойств.
3) Проверка доступа по различным действиям (action).
Замечания и мысли:
Права пользователя можно указать при создании класса в __construct.
При добавлении новых свойств, чтобы не терялись свойства в классе, необходимо будет делать новый класс (клонировать старый с добавлением свойств).
Давайте попробуем это всё реализовать:
class Rights{
private $usrID;//User rights ID
function __construct($user_rightsID){
$this->usrID=$user_rightsID;
}
}$UserRights = new Rights($CurrentUser->rightsID);Рассмотрим добавление права объекта для проверки:
class Rights{
private $group=array();//Сначала нет никаких объектов сравнения
function include_right($grp){
$clone=clone $this;//Чтобы не запортить объект, клонируем его
$clone->group[]=$grp;//Добавляем права клону
return $clone;
}
//... constructor
}Теперь перепишем нашу функцию check, введя её в класс, и посмотрим что получилось:
class Rights{
private $usrID;//User rights ID
private $group=array();//Сначала нет никаких объектов сравнения
function __construct($user_rightsID){
$this->usrID=$user_rightsID;
}
function include_right($grp){
$clone=clone $this;//Чтобы не запортить объект, клонируем его
$clone->group[]=$grp;//Добавляем права клону
return $clone;
}
function check($action){
$result = mysql_query("SELECT * FROM `rights_action` WHERE `RightsID` IN (". implode(",",$this->group) .") AND `action`= '$action' AND `GroupID` IN (SELECT `GroupID` FROM `rights_group` WHERE `RightsID` = ". $this->usrID .")");
if (!$result)
return false;
$tmp=array();
while ($t = mysql_fetch_assoc($result)){
//В каждую из найденных групп (Users, User1, Moderator) пользователей
//заполняем + (0) или - (1) (с приоритетом).
if (!isset($tmp[$t['groupID']]))
$tmp[$t['groupID']] = $t['sign'];
else
$tmp[$t['groupID']] |= $t['sign'];
}
mysql_free_result($result);
if ($tmp)
//Если нашли + в любой из групп, возвращаем true. Иначе false.
return (array_search(0, $tmp) !== FALSE);
//Не нашли ни одного результата $tmp == false
return false;
}
}
* This source code was highlighted with Source Code Highlighter.Сейчас этот класс можно использовать вот так:
//Создаём права пользователя
$UserRights = new Rights($CurrentUser->rightsID);
//Добавляем права объекта, с которыми должен иметь дело пользователь.
$PageRights = $UserRights->include_right($MainPage->rightsID);
//Проверяем, может ли пользователь просматривать страницу?
if ($PageRights->check('messages_view')){
//Да, может. Но что делать с сообщениями?
//Пройдемся по каждому из них
foreach($MainPage->Messages as $msg){
//Добавляем к правам страницы (parent), личные права сообщения (child)
$MsgRights = $PageRights->include_right($msg->rightsID);
//И проверяем на читаемость
if ($MsgRights->check('messages_view')){
//И если оно читается, проверяем можем ли мы редактировать сообщения?
if ($MsgRights->check('messages_edit'))
$msg->editable_flag = 1;
//А удалять сообщения?
if ($MsgRights->check('messages_delete'))
$msg->delete_flag = 1;
DrawMessage($msg);
}
}
}$MainPage — структура страницы, который смотрит пользователь.
$MainPage->Messages — массив сообщений, которые выводятся на странице.
Структуры, предварительно, были считаны из БД.
Оптимизация
Качеством и функциональностью библиотеки мы с вами довольны, но возникает вопрос производительности.
Первое, что бросается в глаза — это при каждой проверке с новым 'action', происходит не хилый SQL запрос. Давайте попробуем это исправить.
Для начала посмотрим, что от запроса к запросу не меняется и оптимизируем это.
SELECT * FROM `rights_action` WHERE `RightsID` IN ( .implode(",",$this->group). ) AND `action`= '$action' AND `GroupID` IN (SELECT `GroupID` FROM `rights_group` WHERE `RightsID` = .$this->usrID. )
Во-первых, каждый раз происходит запрос SELECT `GroupID` FROM `rights_group` WHERE `RightsID` = .... Давайте с него и начнем.
При объявлении UserRights проведем этот запрос один раз, а результат уже будем вставлять в наш SQL-запрос.
function __construct($grp){
$result=mysql_query("SELECT `group_rights`.groupID FROM `group_rights` WHERE `group_rights`.rightsID=$grp");
$this->usrID=array();
while ($t=mysql_fetch_assoc($result)){
$this->usrID[]=$t['groupID'];
}
mysql_free_result($result);
$this->usrID=implode(",",$this->usrID);
}
Уже стало легче, но все равно происходит поиск по всей БД каждый запрос. Как нам от этого можно избавиться? Вероятнее всего, создать предварительный результат, зависящий только от action — потому что выборка `RightsID` и `GroupID` остается неизменной.
Когда добавляется группа объектов, считываем все результаты из БД в массив, который будет зависеть лишь от значений 'action'.
SELECT * FROM `rights_action` WHERE `RightsID` IN (...) AND `GroupID` IN (...)Далее, уже перебором по каждому 'action' в массиве, ищем необходимый элемент. При этом запросов в БД больше нет — до следующего объекта с новыми правами.
В результате оптимизации, наш класс будет выглядеть вот так:
class Rights{
private $group="";
private $usrID=array();
private $temptable="";
function include_right($grp){
$clone=clone $this;
$clone->group[]=$grp;
$result=mysql_query("SELECT * FROM `action_rights` WHERE `action_rights`.groupID IN ({$this->usrID}) AND `action_rights`.rightsID IN (".implode(",",$clone->group).")");
$tmp=array();
while ($t=mysql_fetch_assoc($result)){
$tmp[]=$t;
}
mysql_free_result($result);
$clone->temptable=$tmp;
return $clone;
}
function check($action){
$tmp=array();
foreach ($this->temptable as $t){
if ($t['action']==$action){
if (!isset($tmp[$t['groupID']]))
$tmp[$t['groupID']]=$t['sign'];
else
$tmp[$t['groupID']]|=$t['sign'];
}
}
if ($tmp){
return (array_search(0,$tmp)!==FALSE);
}
return false;
}
function __construct($grp){
$result=mysql_query("SELECT `group_rights`.groupID FROM `group_rights` WHERE `group_rights`.rightsID=$grp");
$this->usrID=array();
while ($t=mysql_fetch_assoc($result)){
$this->usrID[]=$t['groupID'];
}
mysql_free_result($result);
$this->usrID=implode(",",$this->usrID);
}
}
* This source code was highlighted with Source Code Highlighter.Можно ли ещё быстрее?
Да, можно.
1) Если учитывать, например пустые группы прав у сообщений (child), которые не поменяют нашу уже используемую временную таблицу. В этом случае мы можем использовать её, не создавая заново. А для проверки, нам необходимо добавить лишь ещё один SELECT count(*) FROM `action_rights` WHERE `GroupID` =…, который пройдётся по индексу и вернет результат.
2) Правильно расставить индексы в таблицах `action_rights` и `group_rights`.
Тут я не уверен. Эксперты меня надеюсь, поправят. Лично сделал PK — 'rightsID', 'action', 'groupID', INDEX — 'groupID', 'rightsID'
3) После создания Temporary Table, добавлять в неё индекс по 'action': ALTER TABLE `{$this->temptable}` ADD INDEX ( `action` ).
Правда я не уверен, что этот способ тоже действенен. Эксперты, посвятите пожалуйста. :)
4) Использовать кеш. Но это уже другая история :)
Работающий пример
Я думаю, что уже достаточно на сегодня кода. Вот как это работает:
работающий пример — извиняюсь за не наглядность.
test.php (рабочий пример) — здесь используются мои библиотеки, которые работают с SQL БД, не удивляйтесь. Уверен, что разберетесь.
rights.php — наша библиотека.
Расширяемость
Любые новые действия, которые вы будете использовать в вашем проекте добавляются в 'action' ENUM.
Если вы не хотите быть привязанным к конкретным действиям и добавлять их в реальном времени, то стоит заменить 'action' ENUM на integer и создать ещё одну таблицу соответствий actionID с action_name. (как мы сделали это с названиями Групп)
Update: Появилось продолжение: Оптимизации системы разделения прав доступа в веб-приложении
