Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
раздача прав доступа на отдельные строки таблиц
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. Права доступа назначаются каждому пользователю следующим образом: в таблицы acl_view, acl_insert, acl_update, acl_delete вносится следующая информация: user_id – id пользователя которому назначаются права доступа obj_id – id таблицы для которой назначаются права доступа пользователю author_id – id пользователя – автора просматриваемой / изменяемой / удаляемой записи grant – определяет право (true/false) При поле grant = NULL у пользователя есть право выполнения операций над строками внесёнными любым пользователем. Каждая таблица должна иметь поле author_id, которое определяет автора каждой записи. Например при просмотре таблицы на значается фильтр по author_id при помощи функции которая возвращает id пользователей. примерно так: Код: plaintext Разумеется все обращения к таблицам выполняются через функции и представления. Как вам такой вариант решения данной проблемы? ЗЫ Критика и советы обязательны ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2005, 14:22 |
|
||
|
раздача прав доступа на отдельные строки таблиц
|
|||
|---|---|---|---|
|
#18+
ИМХО попытка перенести клиентскую логику на сервер БД. Вариант рабочий, точнее другого особо и не придумаешь. По мне так слишком геморно. На больших таблицах тормоза будут недетские. Но если нужно, то почему бы и нет... В качестве рекомендации советую добавлять поле не владельца строки, а некой группы, в которую данный владелец может входить - так можно сделать доступ на одну строку нескольких пользователей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2005, 17:48 |
|
||
|
раздача прав доступа на отдельные строки таблиц
|
|||
|---|---|---|---|
|
#18+
Поддерживаю Hordi в том, что авторство записи надо делать на группу и права раздавать тоже на группы (авторство удобнее задавать не какой-то группой куда входит пользователь, а фиктивной группой доступа, определяемой по атрибутам записи или самим человеком). Пусть даже первое время придётся делать отдельную группу на каждого пользователя, но иначе при росте системы до 500-1000 пользователей администрировать огромное число записей acl будет не по силам, да и размер офигенный получится. А вот насчет выноса проверки доступа на клиента не согласен - разграничение доступа относится к данным и ИМХО должно производится как можно ближе к ним. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2005, 04:06 |
|
||
|
раздача прав доступа на отдельные строки таблиц
|
|||
|---|---|---|---|
|
#18+
может 1 - все acl_* в одну таблицу +поле тип доступа Может 2 - набор прав в стиле линуха, для владельца, для группы, для других ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2005, 10:03 |
|
||
|
раздача прав доступа на отдельные строки таблиц
|
|||
|---|---|---|---|
|
#18+
Почему бы четыре таблицы acl_* не объеденить в одну добавив поле action_id? (1 - select, 2 - insert, 3 - update, 4 - delete) Не потребуется ли устанавливать права на конкретные строки? :-О джанкерПри поле grant = NULL у пользователя есть право выполнения операций над строками внесёнными любым пользователем.Дефолты наверное правильнее сделать так: grants - user_id # not null - author_id - object_id - action_id # not null - grant # not null При author_id IS NULL и object_id IS NULL и row_id IS NULL юзер имеет такой грант на такое действие на все строки во всех объектах. Строки с author_id IS NOT NULL имеют более высокий приоритет и обозначают права этого юзера на все строки во всех объектах этого автора. Самый высокий - со всеми полями NOT NULL. Проверка тогда должна быть основана на бырорке "select ... where ( author_id = ? or author_id is null ) and ( object_id = ? or object_id is null )", из которой выбирается строка с наибольшим приритетом. (Может быть даже средствами SQL типа "order by author_id not null desc limit 1".) P.S.: Может быть назначать права не на "физические" операции - с таблицами БД, а на "логические" - над объектами, которые там хранятся? (Допустим в БД есть таблица объектов, и таблица свойств этих объектов. Допустим, из логической модели системы следует, что юзер может иметь "логические" права на объекты автора, но при этом обязательно вместе с их свойствами! То есть "физические" права на таблицы objects и object_properties должны быть одинаковыми. При использовании предложенной вами схемы с "физическими" правами имеем дублирование данных, обусловленное логической моделью.) P.P.S.: Disclaimer. :) Мне с такой задачей сталкиваться не приходилось, то есть опыта в этом нет. P.P.P.S.: Вообщето-то этому топику правильнее в форум "Проектирование БД". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.04.2005, 10:52 |
|
||
|
раздача прав доступа на отдельные строки таблиц
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2005, 20:37 |
|
||
|
раздача прав доступа на отдельные строки таблиц
|
|||
|---|---|---|---|
|
#18+
проссматривая старые темы, посмотрел в pg_class ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 14:10 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=33041363&tid=2003758]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
28ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 218ms |
| total: | 341ms |

| 0 / 0 |
