Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
разграничение досупа к информации или как сделать такую ф-ю
|
|||
|---|---|---|---|
|
#18+
встал вопрос о разграничении прав доступа к информации решил реализовать это так: 1. имеется табличка с пользователями ( user_list ) - user_id - user_login - user_name - session_key когда пользователь логинится в системе, то он получает сгенерированный session_key, и в дальнейшем, кидает user_id & session_key в качетве параметров во всех запросах 2. есть табличка с данными доступ к которым надо разграничивать, среди столбцов с данными ( data_list ), в ней есть два поля - maker_id - это user_id пользователя - который создал эту запись - access_list - список user_id, которые могут смотреть эту запись в виде ";2;11;14;15;16" 3. когда пользователь делает запрос, то сперва проверятеся соответствие user_id и session_key на корректность, и только потом делается запрос Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. В принципе, схема работоспособнася, но когда начал проверять от имени пользователей (на админа), то возникла БОЛЬШАЯ проблемма по идее пользователь должен иметь доступ к GET_DATA_LIST а GET_DATA_LIST - должна иметь доступ к user_list и data_list но как оказалось, функция выполняется с правами пользователя который её вызывает то есть, чтобы отработала вышеописанная функция у пользователя как минимум должны быть SELECT права на user_list и data_list всё это теряет смысл, если юзер напрямую имеет доступ к этим таблицам вроде это могут победить вьюхи, но к ним нельзя передать параметра, или можно? как это обойти? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 22:44 |
|
||
|
разграничение досупа к информации или как сделать такую ф-ю
|
|||
|---|---|---|---|
|
#18+
CREATE FUNCTION ... SECURITY DEFINER ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2006, 02:11 |
|
||
|
разграничение досупа к информации или как сделать такую ф-ю
|
|||
|---|---|---|---|
|
#18+
Да, это то, что надо!!! Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2006, 15:14 |
|
||
|
разграничение досупа к информации или как сделать такую ф-ю
|
|||
|---|---|---|---|
|
#18+
Если к базе полный доступ ( типа она под вашем контролем, а не хостинг какойто ) то, помойму, лучше дать пользователям полноценные дб аккаунты. И сделать проверку доступа к строкам таблиц через представления. И пользователям дать доступ к представлениям как к обыкновенным таблицам - программа на клиенте упроститься. И зачем еще какойто ссесион кей придумали? У вас что, в разных ссессиях но для одного пользователя могут быть разные права? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2006, 19:43 |
|
||
|
разграничение досупа к информации или как сделать такую ф-ю
|
|||
|---|---|---|---|
|
#18+
JelisЕсли к базе полный доступ ( типа она под вашем контролем, а не хостинг какойто ) то, помойму, лучше дать пользователям полноценные дб аккаунты. И сделать проверку доступа к строкам таблиц через представления. И пользователям дать доступ к представлениям как к обыкновенным таблицам - программа на клиенте упроститься. База в локальной сети У каждого пользователя будет свой индивидуальный аккоунт Помимо этого есть дополнительная таблица ( user_list ) с фамилиями, отделами, логинами, группами пользователей + морда для оправления пользователями. Если я делаю проверку через представление, то во въюхе можно проверить по имени пользователя (USER). Получается надо для каждой строки хранить список пользователей по именам. а если 10 столбцов с данными, ещё два с именем "создателя" и "списком кому можно смотреть"... выходит будет в полтора раза больше данных, что скажется на быстродействии. На сколько я знаю хранить и обрабатывать циферки гараздо быстрее. Вот и было решено хранить не имена а user_id из user_list JelisИ зачем еще какойто ссесион кей придумали? У вас что, в разных ссессиях но для одного пользователя могут быть разные права? Если использовать вышеуказанную функцию без session_key, то любому другому пользователю, будет достаточно подставить в запрос другой user_id и получить доступ к любым данным в data_list . При подключении пользователя к БД, генерится session_key (md5) и его помнит клиент и база данных. - так я хочу разграничивать доступ к данным а права групп и пользователей будут нужны при реализации "бизнес процессов" Может можно как-то проще? Буду рад подсказкам! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2006, 13:24 |
|
||
|
разграничение досупа к информации или как сделать такую ф-ю
|
|||
|---|---|---|---|
|
#18+
Данные о правах доступа можно хранить в отдельной таблице (persmisson), например с такими полями название таблицы ид_поле в таблице к которому ограничеваеться доступ название столбца ( если нужно еще и ограничение по столбцам... хотя тогда лучше таблицу на две разбить, imho) логин пользователя ( или ид, наверно ид в самом деле лучше, тем более что у вас буде дополнительная таблица по пользователям ) а в представленние делать еще такую проверку AND id IN (SELECT p.id FROM Permission AS p WHERE login = current_user AND table_name = 'our_table'); И все это конечно оптимизировать-нормализировать :-) А в основной таблице вообще убрать любые данные о доступе и доступ к ним простым смертным закрыть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2006, 16:01 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=34054133&tid=2006036]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
49ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 270ms |
| total: | 406ms |

| 0 / 0 |
