Нормален ли такой подход при проверке привилегий пользователя, основываясь принципом passport.privilege?

Здравствуйте.

Делаю систему распределения прав по принципу вашего модуля passport, разобраться в программной части не получается, поэтому придумал некоторую технологию, по которой все это буду делать, и хотел бы узнать ваше мнение, нормален ли такой вариант (уловил ли я суть вашей системы)?

В БД делаю три основные таблицы как в вашей системе (http://popoff.donetsk.ua/text/work/libs/passport/db/privilege.html), правда вместо tynublob, использую пока что char(255).

Привилегии у меня имеют следующий вид:
1) например есть страница подробного описания товара в каталоге /catalog/products.php?catid=59&. productid=1 - здесь я проверяю наличие привилегии products.hidden.59.1 (просмотр товара если он скрыт) и products.edit.1 (редактирование товара) и products.delete.1 (удаление товара)
2) и есть страница управления товарами /admin/catalog/products.php?mode=edit&. catid=59&. productid=1 - здесь я проверяю наличие привилегии products.edit.59.1 - т.е. пользователь может редактировать данный товар.

Для проверки привилегий делаю следующее:
1) Извлекаю все привилегии непосредственно для пользователя, и привилегии выполняемой им роли (role.moderator), в 2 запроса к БД, результат получается в виде списка через запятую. Результат функции загрузки всех привилегий кэширую при помощи PEAR:Cache_Lite.
2) Затем прохожу циклом по привилегии products.edit.59.1, разбивая ее на
products, products.edit, products.edit.59, products.edit.59.1
=> и на каждой интерации цикла сверяю значение привилегии (например: products) со списком привилегий пользователя, проходя уже циклом по массиву привилегий пользователя и при присутствии привилегии у пользователя, торможу цикл: return true;
В результате функция возвращает положительный результат. Значит пользователь имеет привилегию.

Также решил, что при отстутсвии привилегий для пользователя, можно будет делать переменную сессии $_SESSION['privileges'] = 'количество привилегий для пользователя', если их нет то привилегии не проверяем.

Скажите пожалуйста, нормален ли такой подход?
Нормально ли что на одной странице, необходимо проверить сразу несколько привилегий?
И непосредственно в вашей системе все привилегии создаются в ручную, например при добавлении нового модуля, вы в БД заносите имя новой привилегии?

popoff, спасибо большое за ответ.

Вы делаете это из технических или из религиозных соображений? popoff

Я делаю это из-за плохих знаний в программировании и соответсвенно непонимании того, зачем нужно использовать tynyblob. Если вариант с использованием char приемлем, я буду использовать его.

Я у себя нигде не использовал числовые идентификаторы в качестве слов в имени привилегий - везде есть специальное поле с именем файла, который задаётся администратором. popoff

У меня например категории каталога представлены в виде дерева(список смежностей), т.е. например категория с catid=59 (Головодержатели), может быть дочерней по отношению к категории catid=22 (Ортопедические изделия), а у вас наверное к примеру, есть дополнительное поле, содержащее имя файл, например для catid=59 - это /ortizdeliya/golovoderzhateli/, для catid=22 - /ortizdeliya/, получается видимая в строке url иерархия каталогов.

Либо Ваш каталог не может быть иерархическим, либо Вы не правильно поняли, как организуется управление привилегиями в иерархических объектах. popoff

Ну вот к примеру у меня есть папка /catalog/, затем может быть выбрана категория каталога /catalog/?catid=59, в категории может быть выбран товар, /catalog/products.php?catid=59&productid=1, т.е. получается путь catalog.59.products.1 (products == products.php),
в вашей системе вы придумываете имя привилегии text.edit и используете путь a/b/c => text.edit.a.b.c.,
например я придумал привилегию product.edit, добовляю к ней путь и получается => product.edit.catalog.59.products.1 (учитывая то что, категория 59, дочерняя для 22, путь наверное в итоге может быть такой - product.edit.catalog.22.59.products.1),
в результате получается, что product.edit - разрешает редактировать все товары во всех категориях,
теперь наверное это схоже с вашим принципом?

По поводу кеширования как раз сегодня комментировал: ... popoff

Вот с кэшированием я совсем запутался.
В кратце я вижу так: после первой загрузки привилегий, я кэширую результат функции => для того чтобы в последующем не обращаться к БД и уменьшить тем самым нагрузку на нее. При изменении привилегий для пользователя, сбрасывать кэширование, тем самым после обновления страницы изменения вступят в силу. Мне кажется что тако вариант неплохой и вроде я не заблуждаюсь?

popoff, спасибо за ответ.

Я нашел руководство по mysql, почитал про типы столбцов. Основное отличие столбцов с типом BLOB (TYNYBLOB) от CHAR, при сохранение и извлечение завершающие пробелы не удаляются из столбцов BLOB И это двоичные объекты. Я посмотрел, например в GACL, типы столбцов используются varchar.
C вашей помощью, я разобрался с типами столбцов

Я думаю, что этот ваш ответ отвечает на все мои вопросы в предыдущем сообщение.

Хотелбы задать вам только один последний вопрос.
Непосредственно в вашей системе, каким образом вы создаете ноые привилегии:
1) Вручную допустим заносите в БД (при помощи формы) новую привилегию text.edit.a.b.c.d
2) Либо к примеру у вас есть карта сайта, и непосрдественно для определенного url, вы выбираете возможность (уже из созданного списка возможностей), например редактирование, в итоге у вас к примеру получается text.edit.a.b.c.d - что-то схожее с BITRIX.ru

У вас например есть таблица passport_role_privilege
Изначально в ней нет привилегий для ролей. Вы же заносите в БД данных, в эту таблицу список привилегий для роли.
Как вы это делаетет, прям так и ппишеите, например через web форму, k_role = 1, s_privilege = text.edit, b_mode = 1? Как вы это делаете?
Я не смог установить вашу cms, на хостинге при вводе e-mail например, в результате выходит сообщение, онекорректности e-mail. Поэтому хотелбы понять как вы это делаете? У меня нет опыта в программировании, поэтому я неимею представления о том как это делается, ведь тот кто это умеет делать, имеет опыт, и навернека его варинт будет нормален.

Спасибо большое за разъяснения. Который раз я опять читал описание модуля passpot.privileges, и в итоге я представляю что и как мне надо сделать. Cпасибо за статью.