Разграничение полномочий в приложении, работающем с БД

← →
Павел Калугин © (2007-10-31 14:02) [40]

> [34] MOA © (20.10.07 14:06)

Все понимаю.
Но как штатными средствами сервера задать следующее ограничение:
Вася Пупкин может смотреть только те документы которые создал сам
Петя Батарейкин - только то что создал Вася Пупкин и он сам
Федя Курочкин - документы созданные всеми пользователями

← →
Reindeer Moss Eater © (2007-10-31 14:14) [41]

Но как штатными средствами сервера задать следующее ограничение:

Вообще-то с формальной точки зрения, то это делается легко.
:)

← →
Jeer © (2007-10-31 14:21) [42]

> Reindeer Moss Eater © (31.10.07 14:14) [41]

Но вот как средствами сервера модифицировать пользовательский интерфейс:))

← →
Павел Калугин © (2007-10-31 16:42) [43]

> [41] Reindeer Moss Eater © (31.10.07 14:14)

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

← →
Reindeer Moss Eater © (2007-10-31 16:56) [44]

Чем же это не механизм?
Вьюха - объект БД.
Одному даем права, другом не даем, третьему даем не такие права как первому.

← →
Reindeer Moss Eater © (2007-10-31 16:58) [45]

Задействованы средства сервера. Права разграничены.
А то, что какой-то пользовательский интефейс там еще где-то есть, так сервер про это ничего не знает.
:)

← →
stud © (2007-10-31 18:38) [46]

Jeer © (31.10.07 14:21) [42]
Но вот как средствами сервера модифицировать пользовательский интерфейс:))
а при чем тут пользовательский интерфейс???
на сервере к примеру указываем чьи документы может читать вася, а чиь петя. у каждого документа должен быть создатель/владелец, и кто мешает в простом запросе проверить "разрешение" на чтоение нужного документа? интерфейс и тем клиентская часть тут при чем?
или клиент сначала вытаскивает себе всю базу , а потом локально лопапит все это?

← →
Jeer © (2007-11-01 09:41) [47]

> stud © (31.10.07 18:38) [46]

Опять Вы не в теме:))

Пользовательский интерфейс очень даже при чем.
Предположим условно, нам надо реализовать несколько ролей пользователя, например:
- гость
- смотрелка
- оператор
- импортер
- аналитик

Для каждого из них необходимы свои права по доступу к объектам DB, а также настройка пользовательского интерфейса (активны-неактивны, видимы - не видимы те или иные контролы).
Если с первым сервер справится, то со вторым ну ни как:))

← →
Reindeer Moss Eater © (2007-11-01 09:49) [48]

Видимость контрлов никак с разграничением прав доступа к объектам БД не связана.

← →
Anatoly Podgoretsky © (2007-11-01 12:52) [49]

И не только видимость.

← →
stud © (2007-11-01 13:24) [50]

Reindeer Moss Eater © (01.11.07 9:49) [48]
Видимость контрлов никак с разграничением прав доступа к объектам БД не связана

если контрол "не рабочий" какая разница видим он или нет?
обработать исключение и выдать юзеру сообщение - "мало прав..." труда наверное не составит?
да и если уж так хочется почему состояние контролов не впихнуть в бд и потом на клиенет енеблить/неенеблить их? (хотя имхо это извращение)

← →
Павел Калугин © (2007-11-01 13:29) [51]

> Reindeer Moss Eater © (31.10.07 16:56) [44]

именно. Вьюха - объект БД
ее предварительно создать надо.
А я речь веду о разграничении прав доступа к объектам БД.
То есть, грантами только не обойдешся. придется код писать.
на стороне клиента на сторое сервера это второй вопрос (естественно лучше на стороне сервера)
Но только раздачей прав на объекты описанную мною выше ситуацию не разрулишь. Логично? или я опять не прав?

← →
Reindeer Moss Eater © (2007-11-01 14:27) [52]

И чего?
сам объект, права но который надо разграничить тоже надо создавать.

← →
Reindeer Moss Eater © (2007-11-01 14:29) [53]

Логично? или я опять не прав?

Я просто не смешиваю собственно разграничение прав на объекты бд средствами сервера и заморочки с построением пользовательского интерфейса.

Средствами сервера можно разграничить права на любой его обект

← →
Reindeer Moss Eater © (2007-11-01 14:38) [54]

тем более, что есть сервера на которых можно разграничить доступ к строкам вообще без вьюх

← →
Павел Калугин © (2007-11-01 15:15) [55]

> Reindeer Moss Eater ©

Да есть. Но они не носято гордое имя MSSQL :)

> Средствами сервера можно разграничить права на любой его
> обект

Кортеж (запись) в таблице это не объект?

В общем мречь тоя веду о чем. Далеко не все модно разрулить раздачей прав. Думать тщательно надо заранее и проектировать.
И предусмотреть те самые вьюхи. Только тогда - сколько ролей столько и вьюх. (точнее сколько возможных комбинаций ролей)

Или как-то по другому разруливать. Обязательно учтя это разруливание при проектировании структуры базы

Одними грантами тут не обойдешся. Вот о чем речь.

Кортеж (запись) в таблице это не объект?

Если это объект, то тогда у него имя должно быть.

если что-то имеет именованные атрибуты, но само не имеет имени, то это не объект БД.

Тем более, что это имена колонок, а не полей записи.
Запись это не объект БД.
:)

А вообще как вы представляете себе такое.

Якобы есть сервер и в нем есть объекты.
И этот сервер не в состояни контролировать доступ к ним.

Хорошенький сервер надо сказать.

> [59] Reindeer Moss Eater © (02.11.07 12:19)

Я не о том...
Сервер (напоминаю МSSQL сервер, впррочем Sybase тоже ) позволяет настроить допуск до вьюхи, таблицы и так далее.
Он не позволяет разделить доступ до строки, колонки (если эти термины удобнее)
Следовательно возникает необходимость дополнять сушествующий механизм своими дописками, то есть или комплекты вьюх под каждую роль клепать или еще как изголятся.

> Он не позволяет разделить доступ до строки, колонки (если
> эти термины удобнее)

А что по твоему делают Column Permition?

GRANT SELECT ON [Table] ([Column]) TO [User])

Права можно назначить любому ОБЪЕКТУ
Это кстати даже dBase IV поддерживал.

Разграничение полномочий в приложении, работающем с БД Найти похожие ветки