Какой эффективный способ сделать систему разрешений? - PullRequest
Новая
       3

Какой эффективный способ сделать систему разрешений?

5 голосов
/ 12 июня 2010

В настоящее время я просто использую что-то подобное в таблице БД: 

access: home,register,login

А потом на каждой странице: 

if(!Functions::has_rights('content'))
{
     Functions::noAccess();
}

Есть ли более эффективный способ сделать это с php и MySQL? Я могу хотеть получить доступ даже к нескольким частям страницы, например, пользователь может читать страницу, но не комментирует ее, и я не хочу создавать отдельную систему для каждого модуля.

Ответы [ 3 ]

3 голосов
/ 12 июня 2010

Я создал один, используя систему разрешений "* NIX-type".

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

Так, например, у меня есть 

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 для этого)

3 голосов
/ 12 июня 2010

Я считаю, что вы ищете Список контроля доступа , где вы моделируете свою проблему на две вещи: объекты и роли .

Неполный список примеров, которые можно использовать или на которые можно вдохновиться, если написать собственный с нуля:

1 голос
/ 15 июня 2010

Если вы используете какую-либо маршрутизацию, то имеет смысл сделать так, чтобы ваш 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 для просмотра списка.

...