Посоветуйте реализацию прав пользователей

[Curly-fingers]

Посоветуйте реализацию прав пользователей

Здравствуйте!
Посоветуйте как правильно поступить.
Есть таблица permisions в БД такой структуры:
id | user_id | module_id | permision
а также класс в котором метод нехитрым запросом, но длинным, выбирает все права для одного модуля и одного пользователя и возвращат значение в виде масива $permisions['some_permision'] = true;
Теперь вопрос: как лучшее сделать проверку прав.
У меня две идеи:
- проверять наличие елементов масива обичними ifами и если true, тогда вывод некорых данных для конкретного права;
- в цикле выбирать все права из даного масива и уже относительно их запускать функцию, например PermisionCall($permision); где $permision - индекс елементов даного масива, которая будет уже заниматься проверкой наличия прав и формировать уже последующие данные;
Посоветуйте пожайлуста.

 

[Фанат]

google ACL

 

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

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

В системе есть пользователи. Они делятся на пользователей и пользователей с правами - модераторы.

В систему я ввел два понятия - action и operation.

Action - это обобщённое понятие действия. Action - это, например, вывод списка пользователей:
/admin/?action=users_list

Operation - это частное локальное действие, относящщеся к модулю Action. В случае использования модуля users_list операции будут такие, например:
/admin/?action=users_list&operation=user_delete&user_id=12 - операция удаление пользователя
/admin/?action=users_list&operation=user_ban&user_id=12 - операция блокировка пользователя
/admin/?action=users_list&operation=user_edit&user_id=12 - операция редактирования пользователя

Есть таблицы:

users_actions

id_user | id_action | access

users_operations

id_user | id_action | id_operation | access

Смысл, думаю понятен.

При авторизации пользователя, если он модератор, мы выбираем права на Actions и права на Operations,
и смотрим, может ли пользователь выполнять то или иное действие.

Какой-то Action, если он в 1, имеет приоритет над Operation. Иначе - смотрим разрешение на конкретный Operation.

Плюсы очевидны - я могу дать каждому человеку индивидуальные права на каждое действие. Например, я хочу позволить модератору редактировать пользователей, но запретить удалять их и банить - пожалуйста! А если мне этого не надо - даю права на вес Action.

Также я реализовал супер-админа, которому проверка на operations вообще не требуется. Но про это лень писать )

-~{}~ 07.11.07 10:27:

как лучшее сделать проверку прав

как удобно, так и делай. Логику тут за тебя никто не напишет.

 

[Curly-fingers]

google ACL

Спасибо. Очень полезная информация.
triumvirat
Суть Вашего подхода ясна. У меня примерно то что и у Вас.
Спасибо.

 

[asterisk]

а если сократить до одной таблицы и при этом избавиться от необходимости запоминать что например operation == 1 это удаление(добавление/редактирование) записи.

т.е. что то вроде:
table: permission
id | UserId | action | method |

пример: 1, 666, news, add

мой вариант мне кажется более наглядным и не требовательным к детальному документированию системы.

Также я реализовал супер-админа, которому проверка на operations вообще не требуется. Но про это лень писать )

даже боюсь представить на сколько понятие "супер-админа" может быть сложно описано в логике если это так лень объяснять.

что мешает супер админа представлять как:
id | UserId | action | method |
111 | 222 | all | all |
?

 

[Mr_Max]

http://popoff.donetsk.ua/text/work/libs/passport/privilege/

 

[Nelius]

Мой вариант:

id | user_id | module_id | permision
1 15 news 1110

где 1110 - первая цифра просмотр(1 - да, 0 - нет),
вторая цифра добавление, третья редактирование, четвертая - удаление.
1111 - полный доступ.

 

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

а если сократить до одной таблицы и при этом избавиться от необходимости запоминать что например operation == 1 это удаление(добавление/редактирование) записи.

т.е. что то вроде:
table: permission
id | UserId | action | method |

так тоже можно. но в данном случае нельзя объединить действия в одно основное.

где 1110 - первая цифра просмотр(1 - да, 0 - нет),
вторая цифра добавление, третья редактирование, четвертая - удаление.
1111 - полный доступ.

ИМХО, не вяжетццо с этим: Реляционная СУБД

 

[MiksIr]

Мой совет в копилку - начинайте думать ролями, а не пользователями. Когда у вас их будет больше, чем десяток - пригодится.

 

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

MiksIr
Роли - это вообще частный случай. Мне в моей системе роли нафик не нужны, ибо я уверен, что модераторов будет не более 3-5 человек. Ну и если их даже 20 будет, хоть 30 - сложно будет ручками выставить им права, я не пойму?

Мне вообще сложно представить ситуацию, в которой роли реально нужны.

 

[Nelius]

Автор оригинала: triumvirat
ИМХО, не вяжетццо с этим: Реляционная СУБД

и с чем из этого конкретно не вяжется?

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

 

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

каждый элемент таблицы — один элемент данных

у тебя элементы данных - разрешение на определенное действие

просмотр ... добавление ... редактирование ... удаление ... полный доступ.

содержатся в одной ячейке - permision

Зачем это нужно и почему нельзя их разделить по записям - я не пойму. Зато прелесть от обновления, редактирования и удаления этих прав я уже себе представляю........

 

[Nelius]

ну так это и есть один элемент данных, ни что иное как целое число...

а вы предлагаете
id | user_id | module_id | view | add | edit | delete
1 | 15 | NEWS | 1 | 1 | 1 | 0

?

 

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

я отписал выше, что я предлагаю, во втором посте.

если не делать как я, а оперировать одним понятием action, то получим

id_user | id_action | access

Всё. Ничего сложного.

 

[asterisk]

Nelius

id | user_id | module_id | permision
1 15 news 1110

логика переизбытком лайк условий не страдает?

MiksIr

Мой совет в копилку - начинайте думать ролями, а не пользователями. Когда у вас их будет больше, чем десяток - пригодится.

Аргументируй если не затруднит. пока пост смахивает на пост каунт

 

[Nelius]

Автор оригинала: asterisk
Nelius

логика переизбытком лайк условий не страдает?

Если вы имеете ввиду LIKE то оно вообще тут не используется.

Проверить есть ли у пользователя c ID 15 права на добавление NEWS

SELECT permissions FROM tbl_perms WHERE user_id=15 && module_id='news'

далее в скрипте

if ($perms > 1000) {
права на добавление есть
}

Довольно оригинально, но все же))) По образу и подобию в линуксе -rwx-------

 

[Curly-fingers]

Простите, а как же случай когда прав должно быть больше чем 4 (смотреть, добавить, редактировать, удалить)? Как тогда обходиться? У меня реализировано так: для каждого пользователя имеется несколько записей в таблице вида, как в первом посте, с перечислением модулей и прав. Например:
id | user_id | module_id | permision
1 | 1 | 1 | create
1 | 1 | 1 | edit
1 | 1 | 1 | delete
1 | 1 | 1 | publish
1 | 1 | 1 | view
1 | 1 | 1 | comment
Может ли "аукнуться" мне чем-то такой подход?

 

[asterisk]

Curly-fingers
дааа нееет, юсай
единственное что не понятно, зачем module_id тип int, а permission тип string?
imho для наглядности и себя любимого делаю так:
id | user_id | module_id | permision
1 | 1 | news | create
1 | 1 | news | edit
1 | 1 | news | delete
1 | 1 | news | SuperNerealniyMethod
1 | 1 | news | ...
1 | 1 | superMod | create
1 | 1 | superMod | edit
1 | 1 | superMod | delete

 

[MiksIr]

Считайте это чем хотите.

Чем роль отличается от юзера? В первую очередь мышлением, т.е. тем, чем плоскописание отличается от ООП. Зачем нужен ООП? Что бы снизить стоимость поддержки и расширяемости, вот затем же нужны роли.

Роли - это не частный случай, скорее все остальное частный случай ролей. С помощью ролей и наследованием их прав можно реализовать и плоскую схему юзер-права, и двумерную юзер-права-группа-права и многомерную.

 

[Curly-fingers]

а permission тип string

А какая альтернатива тогда?

зачем module_id тип int

Наверно из-за того что каждый модуль имеет свой id.