Что эффективный путь состоит в том, чтобы сделать системой разрешения?
В настоящее время я просто использую что-то вроде этого в Таблице базы данных:
access: home,register,login
И затем на каждой странице:
if(!Functions::has_rights('content'))
{
Functions::noAccess();
}
там более эффективный путь состоит в том, чтобы сделать это с php и MySQL? Я могу хотеть получить доступ даже к нескольким частям страница, например, пользователь может прочитать страницу, но не делает комментариев к ней, и я не хочу создавать отдельную систему к каждому модулю.
3 ответа
Я думаю, что то, что вы ищете, это Access Control List, где вы моделируете свою проблему на две вещи: объекты и роли.
Неполный список примеров, которые можно использовать или вдохновиться ими, если писать собственный с нуля:
- Zend предоставляет Zend_Acl
- Symphony 3.x имеет ACL, для Symphony 4.x вы можете использовать ACL Bundle и Voters.
- В CakePHP есть ACL плагин
Я построил один, используя систему разрешений типа «* NIX».
У меня есть разные типы разрешений для страницы (чтение, изменение, удаление, комментирование, голосование), и я назначаю бит для каждой из них.
Так, например, у меня есть
define ('USER_CANREAD', 1);
define ('USER_CANMODIFY', 2);
define ('USER_CANDELETE', 4);
define ('USER_CANINSERT', 8);
define ('USER_CANCOMMENT', 16);
define ('USER_CANVOTE', 32);
Тогда, если пользователь может читать, комментировать и голосовать, разрешение будет 1 + 16 + 32 = 49
Чтобы проверить разрешения, я просто выполняю побитовое И с этими значениями.
Например, user-> permissions & USER_CANDELETE , чтобы проверить, может ли пользователь удалить страницу (очевидно, у меня для этого есть функция canDelete )
Если вы используете какой-либо вид маршрутизации, имеет смысл сделать ваш ACL (список контроля доступа) зависимым от маршрутизации, которую вы определили.
Обычно я использую таблицу разрешений и таблицу permissions_users во взаимосвязи HABTM. Таким образом, когда маршрутизация совпадает, можно найти разрешение. Если у пользователя нет разрешения, ему отказывают в доступе. Это можно улучшить, проверив различные типы методов GET, POST, PUT и DELETE.
Это потому, что мне нравится возможность редактировать разрешения и настройки через веб-интерфейс и позволять людям, не связанным с ИТ, делать то же самое (т. Е. Маркетологам).
Вот схема:
+-----------------------+
| permissions |
+-----------------------+
| id | pattern | method |
+-----------------------+
| 1 | | GET | # => Will hit the root of your application
| 2 | users | GET | # => Will hit users/, usually listing the users
| 3 | users | PUT | # => Will hit anyone trying to insert a new user into the system.
| 4 | users/:id | GET | # => Will hit anyone who tries to view a specific user
| 5 | users/:id | POST | # => Will hit anyone trying to update a user
+-----------------------+
+-------------------------+
| permissions_users |
+-------------------------+
| user_id | permission_id |
+-------------------------+
| 1 | 1 | # => Will allow to view the root of the application
| 1 | 2 | # => Will allow to view the users list
+-------------------------+
Итак, пользователь 1 не имеет никаких прав, которые могли бы изменять записи. А поскольку маршрутизация определяет, куда направляются различные методы запроса, вы не можете просто выполнить POST в / users, чтобы просмотреть список.