|
|
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
Вот что в итоге получилось: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Группы могут иметь 2 уровня вложенности Во всех таблицах присутствует поле author_id Для каждой таблыцы есть триггер который проверяет право на требуемый уровень доступа Код: 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. При выборке данных селектом используется условие Код: plaintext время выполнения селектов увеличилось на ~120мс независимо от количества записей в таблицах время выполнения инсертов,апдейтов и делитов измерю позже как вам такой вариант решения проблемы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2005, 20:33 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
джанкервремя выполнения селектов увеличилось на ~120мс независимо от количества записей в таблицах Очень интересно. А какое максимальное кол-во записей в acl и objects в тесте? У нас похожая схема проверки построчного доступа (только не на PostgreSQL) напрочь убивает некоторые запросы на больших таблицах. При update/insert/delete быстро проверяются права на небольшое число строк, а вот хорошей скорости select непросто достичь. Частичные/функциональные индексы используются? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 03:40 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
2 джанкер: киньте пожалуйста explain analyze для нескольких select-ов 2 all: вот что обсуждалось ранее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 09:41 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
Лучше мне кажется в Оракле. Есть специальные средства - Тщательный контроль доступа. Там просто динамически в любой запрос к табле подставляется WHERE с условием, которое пожелал разработчик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2005, 17:17 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
В Sybase ASE тоже аналогичная штучка есть: Row-level access control, но за отдельные деньги. Подозреваю что у Оракла тоже. И всё опять же упирается в функцию проверки прав во WHERE - как напишешь, с такой скоростью и будет работать. Конечно для простой системы, где все пользователи должны видеть только свои данные всё просто. Но когда начинаешь усложнять проверку (проверять вхождение пользователя в группы например) - чтобы не тормозило надо очень постараться. А при большом числе пользователей в системе уровня предприятия это просто необходимо, иначе ни о какой безопасности речь не идет - никакой админ не согласится целыми днями давать/отбирать права лично каждому - он скорее всего даст кучу лишних прав чтобы от него отвязались. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2005, 03:35 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
Если это была бы хорошей идеей, то она давно была бы встроена в SQL и рекомендавалась бы особо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2005, 09:24 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
> Если это была бы хорошей идеей, то она давно была бы встроена в SQL и рекомендавалась бы особо А Вы смотрите на это как на динамическме представления, которые в зависмости от юзера привистовыают к табле, в каком бы она запросе не была where c усовием, которое прописал разработчик. Представления встроены в SQL . Но их может понадобиться туча для аналогичного. Да и приложение переделывать во многих местах. Кроме того, раз уже, как минимум, две СУБД это поддерживают, то, скорее всего, это не так уж и плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2005, 21:23 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
Я то , в принципе, не против. чего только не делаешь для упрощения структуры БД. Просто SQL и Update - понятия не очень совместимые. Insert еще куда не шла. Как OLAP предназначен для многомерного анализа, так и SQL для плоского. Должен быть дополнительный слой работы с полями и записями. Те.ввод и изменения данных должны происходить в другой системе, а результаты передаватся в SQL-OLAP для плоских и многомерных отчетов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.05.2005, 22:48 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
после праздников выложу EXPLAIN ANALYZE пока могу сказать только ~12000 юзеров ~300 групп ~60000 записей в acl на скорость выборки из таблицы 9 млн записей не особо влияет в сложных запросах на маленких таблицах тоже в общем точные цифры скоро будут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2005, 18:19 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов Просто SQL и Update - понятия не очень совместимые. Insert еще куда не шла. Не совсем ясна мысль. В свете того, что SQL - язык БД, а Update - прямая обязанность языка БД. Кроме того, Update можно воспринимать как delete и Insert. Поэтому они тоже тада должны выглядеть как не очень совместимые с SQL. Что тада от него останется? Только чтение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2005, 19:03 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
Подобная тема уже обсуждалась здесь Сам я придерживаюсь такой концепции: ACL для РСУБД не есть хорошо. Действительно это намного медленне чем RWD/Unix Когда-то давно была написана статья В ней тоже разделены понятия ACL и RWD. А в конце загадочные строки "Продолжение следует! Далее будут: объединение схем RWD и ACL" Я до сих пор не понял, как можно (и возможно ли вообще?) объединить эти две модели так, чтоб получить скорость от RWD/Unix и удобства управления правами от ACL. Если кто-то имеет информацию о подобном миксе отзовитесь пожалуйста! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2005, 23:35 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#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. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2005, 12:28 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
джанкер Код: plaintext 1. 2. 3. 4. Может быть вообще получится вместо функций __proc_main_acl_users_get, __proc_main_acl_user_get сделать view. Тогда постгрес будет сам выбирать план выполнения: "а-ля users_get" или "а-ля user_get". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2005, 11:15 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
"раздача прав доступа на конкретные строки таблиц" - не соответствует содержанию. Т.к. в вашем варианте, как мне кажется, вы разделяете доступ к строкам созданным тем же человеком. А если надо смотреть чужие строки... Как вы собираетесь это показать? Почему вы все не заменить на: Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2005, 12:56 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
2LeXa NalBat: LeXa NalBat Четыре десятых секунды на проверку прав на две строки (из таблицы mu). :-( Гораздо быстрее это вроде бы сделать с помощью аналогичной функции с дополнительным аргументом author_id: select ... from __trade_var_of_measuring_units mu where exists ( select 1 from __proc_main_acl_user_get('__trade_var_of_measuring_units',1,mu.author_id)). Думаю, что таким образом первый запрос можно ускорить с 1.9 до 1.1 секунды. попробую поэкпериментировать с этим :)) LeXa NalBat Может быть вообще получится вместо функций __proc_main_acl_users_get, __proc_main_acl_user_get сделать view. Тогда постгрес будет сам выбирать план выполнения: "а-ля users_get" или "а-ля user_get". что то мне не представляется возможным написание такой вьюхи... вот как выглядит __proc_main_acl_users_get: Код: 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. 2BusyMan: BusyManПочему вы все не заменить на: Код: plaintext в таком случае юзер увидит только свои записи а надо чтобы он имел возможность увидеть записи членов своей группы, членов родительской группы или же записи всех пользователей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2005, 14:31 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
Невозможно вот так вот строго разбить пользователей на группы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2005, 15:13 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
А что вы делаете, если триггер выдает raise exception для операции update в ситуации, когда этот update вызван констрейнтом на справочник с on update cascade ? Да, ссылочная целостность соблюдется, но если нужно просто поменять какой-нить код в справочнике, то для этого надо быть юзером с ПОЛНЫМИ правами, а не только правами на изменяемую запись в справочнике. Ну ладно - справочники, можно жить с тем, что их только админы и меняют. А если это таблицы системы документооборота с цепочечными схемами обработки документов ? И тогда у юзеров будут вопросы типа "Шеф сказал мне подправить номер моего договора, а я не могу, пишет, шо нет прав на обновление таблицы ПлановаяПрибыльПоКонтрактам... А ШО ЭТО за таблица ?" Юзер (и, возможно, его шеф) и знать не знает, что такая таблица где-то там ведется, а тут ему такое вываливает ... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2005, 20:19 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
инфо к размышлению просматривая все по теме строчных прав наткнулся на эту старую тему. И посмотрел, что же творит сам PostgreSQL - т.е. где он хранит права. таки посмотрев в скрипт вью Код: plaintext Код: plaintext Одной таблички ему хватает ибо тип поля - массив типа Код: plaintext Код: plaintext вот думаю: дает ди такое хранение какие-то преимущества? С одной - джойнится с кросс таблицей прав не надо - она вся (джойновая часть) лежит в поле. С другой - можно даже какими-то функциональными индексами попытаться обвешаться по такому полю (только вот какими надо?) и его вхождению... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 14:06 |
|
||
|
раздача прав доступа на конкретные строки таблиц
|
|||
|---|---|---|---|
|
#18+
джанкеркак вам такой вариант решения проблемы? Никак. Проверять надо только право на чтение юзером объекта. Для этого автоматом (на основе классификации юзеров и объектов) строится таблица доступа юзер-объект-уровень доступа. Уровень доступа - понятие семантическое и зависит от типа объекта. А все изменения данных - это функции, права на которые раздаются отдельно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 14:55 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=94&tid=1543507]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
140ms |
get topic data: |
17ms |
get forum data: |
3ms |
get page messages: |
163ms |
get tp. blocked users: |
1ms |
| others: | 280ms |
| total: | 641ms |

| 0 / 0 |
