|
|
|
Организация представлений
|
|||
|---|---|---|---|
|
#18+
Добрый день, уважаемые! Подскажите, как организовать доступ к одной таблице БД разных пользователей, чтобы изолировать выборку от других? На примере: user_login private_data1 img231 img132 img333 img253 img29 Пользователь заходит под своим логином и видит только те данные, которые соответствуют ему. В настоящем, на клиенте запрос формируется как Код: sql 1. Но, если зайти через стороннее ПО и ввести Код: sql 1. то увидим все. Знаю, что можно сделать представление и на него навесить права, но тогда нужно 1 (или более) представлений на каждого пользователя. Когда пользователей, например, 1000, то это не вариант... Как решаются подобные примеры? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2015, 19:07:55 |
|
||
|
Организация представлений
|
|||
|---|---|---|---|
|
#18+
Stark3, не обязательно, можно попробовать и одним представлением сделать, с параметром- функцией или на процедурах ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2015, 20:29:43 |
|
||
|
Организация представлений
|
|||
|---|---|---|---|
|
#18+
Партиционировать таблицу. А список доступных разделов (и соответствующую временную MERGE-таблицу) формировать по учётной записи в соответствии с её правами хранимой процедурой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2015, 20:58:52 |
|
||
|
Организация представлений
|
|||
|---|---|---|---|
|
#18+
AkinaА список доступных разделов (и соответствующую временную MERGE-таблицу) формировать по учётной записи в соответствии с её правами хранимой процедурой.Это как? В MySQL же нет системы назначения прав по партициям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2015, 21:02:33 |
|
||
|
Организация представлений
|
|||
|---|---|---|---|
|
#18+
miksoftВ MySQL же нет системы назначения прав по партициям. Зря я написал слово "партиционировать". Надеялся, что термин MERGE объяснит, что я хочу сказать. Не получилось... В общем, каждая уникальная комбинация прав доступа - своя таблица (или фильтрующее представление). А для комбинации нескольких наборов прав - объединение. ХП же возвращает имя объекта, через который следует выполнять доступ к данным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.12.2015, 23:26:21 |
|
||
|
Организация представлений
|
|||
|---|---|---|---|
|
#18+
Stark3, ...сам не проверял, но может получится: сделать вьюшку типа: Код: sql 1. 2. 3. 4. всем пользователям и сторонним ПО дать права на public_table_name а себе оставить права на private_table_name. Самое интересное что вернет USER(), есть подозрение что вернет пользователя. Дял сведения CURRENT_USER() точно вернет создателя ибо SQL SECURITY DEFINER. Если же USER() тоже не вернет пользователя, то продется сделать функцию: create function real_user() returns varchar(64) as return USER(); если и это не поможет, то create function real_user() returns varchar(64) as return @abracadabra; @abracadabra = CURRENT_USER() можно выставить триггером на соединение. SET GLOBAL init_connect = "CALL login_trigger()"; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2015, 04:43:54 |
|
||
|
Организация представлений
|
|||
|---|---|---|---|
|
#18+
MasterZiv...или на процедурах Спасибо, решено сделать именно на хп . Подскажите, вызывающий хп гарантированно не сможет получить права определяющего, верно?) AkinaВ общем, каждая уникальная комбинация прав доступа - своя таблица (или фильтрующее представление). А для комбинации нескольких наборов прав - объединение. ХП же возвращает имя объекта, через который следует выполнять доступ к данным. Честно, без бутылки не разберусь, но спасибо за совет. javajdbc...сделать вьюшку типа... Спасибо за совет, интересно сработает ли, на досуге попробую. Но с первого взгляда под CURRENT_USER() напрашивается SUBSTRING_INDEX, чтобы отделить логин от хоста. Плюс для моей задачи этот способ не сработает т.к. от введенного логина через таблицу соответствий должен браться табельный номер - и уже от него происходят все запросы в БД (я не говорил об этом, чтобы упростить пример) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2015, 09:35:58 |
|
||
|
Организация представлений
|
|||
|---|---|---|---|
|
#18+
Stark3вызывающий хп гарантированно не сможет получить права определяющего, верно? Зависит от SQL SECURITY. Если INVOKER, то да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2015, 09:44:29 |
|
||
|
Организация представлений
|
|||
|---|---|---|---|
|
#18+
AkinaЗависит от SQL SECURITY. Если INVOKER, то да. Благодарю! Очень хороший форум и жители, всегда быстро и точно получаю ответы :) С наступающим всех! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2015, 09:59:06 |
|
||
|
Организация представлений
|
|||
|---|---|---|---|
|
#18+
Самое интересное что вернет USER(), есть подозрение что вернет пользователя Подтверждаю, возвращает при DEFINER вызывающего пользователя, а не определяющего. Очень помогло, спс ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2015, 11:16:38 |
|
||
|
Организация представлений
|
|||
|---|---|---|---|
|
#18+
Stark3 Плюс для моей задачи этот способ не сработает т.к. от введенного логина через таблицу соответствий должен браться табельный номер - и уже от него происходят все запросы в БД (я не говорил об этом, чтобы упростить пример) ...ок, без проблем, парочка решений: 1. добавить таблицу соответсвеий во вью, или 2. по тригеру на соединение записать табельный номер пользователя в какую-нибудь юзер-дефинед переменную и сделать функцию GET_REAL_USER_ID()которая возврашает этот номер. Внутри view можно вызывать функции. Код: sql 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2015, 14:59:40 |
|
||
|
Организация представлений
|
|||
|---|---|---|---|
|
#18+
Stark3Самое интересное что вернет USER(), есть подозрение что вернет пользователя Подтверждаю, возвращает при DEFINER вызывающего пользователя, а не определяющего. Очень помогло, спс O! спасибо! будем знать! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2015, 15:00:34 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39130148&tid=1832365]: |
0ms |
get settings: |
5ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
160ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 430ms |

| 0 / 0 |
