powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Разные права на доступ к данным
6 сообщений из 6, страница 1 из 1
Разные права на доступ к данным
    #32027854
Варяг
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Рискну перебросить мсж из Вопрос-ответ сюда - здесь активность выше!
Такой же вопрос задал и Дмитрий в "Вопрос-ответ" от 17 Nov, 2001 00:30:27
У Мамаева в учебнике долго говорится о возможности горизонтальной и вертикальной
фильтрации при доступе к данным, обеспечиваемых на уровне сервера.
Как я это понял в отношении таблиц, есть некоторые средства, при которых на запрос
типа
select * from <table>
юзером будет получено только то, что ему положено знать.
Если вертикальная фильтрация заключена в запрете выбора колонки через
Permissions(т.е. через Grant/Deny на select из колонки),
то такой запрос выпадает.
Следует перечислять доступные колонки,
что при работе с большой по составу полей структурой крайне неудобно!
При этом вообще ничего нет по горизонтальной фильтрации!
Если же переходить на представления,
то горизонталь как-то еще можно обеспечить через WHERE, но с колонками та же бодяга!
Полный же переход на View приводит к построению кучи разных представлений для каждой роли, юзера и тд. Программирование приложений при этом резко усложняется ,
а все умные разговоры из книжки вызывают недоумение.
Нет ли приемов, как не выпасть на простом запросе по * и при этом не увидеть ничего лишнего ?
...
Рейтинг: 0 / 0
Разные права на доступ к данным
    #32027880
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть еще Application Role.
...
Рейтинг: 0 / 0
Разные права на доступ к данным
    #32027890
Makar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
реализация многоуровневой системы безопасности

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 права_человека;
...
Рейтинг: 0 / 0
Разные права на доступ к данным
    #32027908
Sergey Vinogradov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хм, использовать * в реальном приложении? А если поля в таблице кто-нибудь местами поменяет?
У нас такая конструкция встречается только в виде exists ( select * from ... ).

В любом случае в нормальной системе придется полностью определять все поля в запросе.
И необязательно это делать руками - можно создавать автоматом на основе метаданных.

Если нужно часть полей/строк убрать из видимости для конкретного пользователя,
то можно проверить его права (из сответствующей таблицы прав)
и добавить дополнительное условие к запросу,
а часть выводимых полей заменить на null, либо вообще убрать из запроса.
Опять же, все это пишется один раз и легко используется.
...
Рейтинг: 0 / 0
Разные права на доступ к данным
    #32027949
Варяг
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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
Уже несколько раз видел, как для некоторых крутых приложений в базе сервера строятся свои таблицы логинов, ролей и тд.
То есть модели, предлагаемые Билом Г. очень многих не устраивают. Способ мышления и менталитет у них очень от нас отличается!
Подозревал, что это тянется от древних версий и что-то должно меняться к лучшему, но пока не вижу.
Городить же свои средства безопасности при таком сервере вроде не хочется, иначе все сведется к файл-серверу!
...
Рейтинг: 0 / 0
Разные права на доступ к данным
    #32027951
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IMHO
я вижу, что вы пытаетесь построить 3-х уровневую система на 2-х уровнях, распределив обязанности Application server-а между сервером базы данных и клиентским приложением. Считаю это трудоемким и тупиковым вариантом. Если вы хотите не зависеть от SQL сервера и использовать его только как хранилище данных, то создавайте полноценный Application server, который будет реализовывать ВСЮ вашу бизнесс-логику и отвечать за метаданные. А заодно уже и за права пользователей вашей системы.
...
Рейтинг: 0 / 0
6 сообщений из 6, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Разные права на доступ к данным
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]