Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Разные права на доступ к данным
|
|||
|---|---|---|---|
|
#18+
Рискну перебросить мсж из Вопрос-ответ сюда - здесь активность выше! Такой же вопрос задал и Дмитрий в "Вопрос-ответ" от 17 Nov, 2001 00:30:27 У Мамаева в учебнике долго говорится о возможности горизонтальной и вертикальной фильтрации при доступе к данным, обеспечиваемых на уровне сервера. Как я это понял в отношении таблиц, есть некоторые средства, при которых на запрос типа select * from <table> юзером будет получено только то, что ему положено знать. Если вертикальная фильтрация заключена в запрете выбора колонки через Permissions(т.е. через Grant/Deny на select из колонки), то такой запрос выпадает. Следует перечислять доступные колонки, что при работе с большой по составу полей структурой крайне неудобно! При этом вообще ничего нет по горизонтальной фильтрации! Если же переходить на представления, то горизонталь как-то еще можно обеспечить через WHERE, но с колонками та же бодяга! Полный же переход на View приводит к построению кучи разных представлений для каждой роли, юзера и тд. Программирование приложений при этом резко усложняется , а все умные разговоры из книжки вызывают недоумение. Нет ли приемов, как не выпасть на простом запросе по * и при этом не увидеть ничего лишнего ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2002, 09:43 |
|
||
|
Разные права на доступ к данным
|
|||
|---|---|---|---|
|
#18+
Есть еще Application Role. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2002, 12:33 |
|
||
|
Разные права на доступ к данным
|
|||
|---|---|---|---|
|
#18+
реализация многоуровневой системы безопасности CREATE TABLE информация ( id_информация INTEGER NOT NULL, уровень_допуска INTEGER NOT NULL ); CREATE UNIQUE INDEX XPKинформация ON информация ( id_информация ); ALTER TABLE информация ADD PRIMARY KEY (id_информация); CREATE TABLE права_человека ( id_user INTEGER NOT NULL, уровень_допуска INTEGER NOT NULL ); CREATE UNIQUE INDEX XPKправа_человека ON права_человека ( id_user ); ALTER TABLE права_человека ADD PRIMARY KEY (id_user); CREATE TABLE уровень_доступа ( уровень_допуска INTEGER NOT NULL ); CREATE UNIQUE INDEX XPKуровень_доступа ON уровень_доступа ( уровень_допуска ); ALTER TABLE уровень_доступа ADD PRIMARY KEY (уровень_допуска); CREATE TABLE человек ( id_человек INTEGER NOT NULL, last_name last_name_, id_user INTEGER, first_name first_name_, mid_name mid_name_ ); CREATE UNIQUE INDEX XPKчеловек ON человек ( id_человек ); ALTER TABLE человек ADD PRIMARY KEY (id_человек); ALTER TABLE информация ADD FOREIGN KEY (уровень_допуска) REFERENCES уровень_доступа; ALTER TABLE права_человека ADD FOREIGN KEY (уровень_допуска) REFERENCES уровень_доступа; ALTER TABLE человек ADD FOREIGN KEY (id_user) REFERENCES права_человека; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2002, 15:08 |
|
||
|
Разные права на доступ к данным
|
|||
|---|---|---|---|
|
#18+
Хм, использовать * в реальном приложении? А если поля в таблице кто-нибудь местами поменяет? У нас такая конструкция встречается только в виде exists ( select * from ... ). В любом случае в нормальной системе придется полностью определять все поля в запросе. И необязательно это делать руками - можно создавать автоматом на основе метаданных. Если нужно часть полей/строк убрать из видимости для конкретного пользователя, то можно проверить его права (из сответствующей таблицы прав) и добавить дополнительное условие к запросу, а часть выводимых полей заменить на null, либо вообще убрать из запроса. Опять же, все это пишется один раз и легко используется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2002, 01:07 |
|
||
|
Разные права на доступ к данным
|
|||
|---|---|---|---|
|
#18+
2Glory Спасибо за подсказку! Но это не совсем то! Пусть с этими ролями мы запретим работнику видеть зарплаты (в т.ч. и руководителя), а тому будет разрешено ее видеть и править.Это можно реализовать одним приложением, учитывающим гранты для текущего пользователя. Но как этими ролями запретить видеть зарплаты соседнего подразделения? Строить некое представление, где в WHERE это и будет учитываться? Но тогда мы уже работаем не с таблицей, и при этом возникают свои вопросы http://www.sql.ru/cgi-bin/UltraBoard/UltraBoard.pl?Action=ShowPost&Board=mssql&Post=5112&Idle=365&Sort=0&Order=Descend&Page=0&Session= 2makar Уже несколько раз видел, как для некоторых крутых приложений в базе сервера строятся свои таблицы логинов, ролей и тд. То есть модели, предлагаемые Билом Г. очень многих не устраивают. Способ мышления и менталитет у них очень от нас отличается! Подозревал, что это тянется от древних версий и что-то должно меняться к лучшему, но пока не вижу. Городить же свои средства безопасности при таком сервере вроде не хочется, иначе все сведется к файл-серверу! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2002, 10:01 |
|
||
|
Разные права на доступ к данным
|
|||
|---|---|---|---|
|
#18+
IMHO я вижу, что вы пытаетесь построить 3-х уровневую система на 2-х уровнях, распределив обязанности Application server-а между сервером базы данных и клиентским приложением. Считаю это трудоемким и тупиковым вариантом. Если вы хотите не зависеть от SQL сервера и использовать его только как хранилище данных, то создавайте полноценный Application server, который будет реализовывать ВСЮ вашу бизнесс-логику и отвечать за метаданные. А заодно уже и за права пользователей вашей системы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2002, 10:15 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32027908&tid=1823080]: |
0ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
46ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
28ms |
get tp. blocked users: |
1ms |
| others: | 249ms |
| total: | 352ms |

| 0 / 0 |
