Управление доступом к отдельным полям

← →
Mr. D. (2007-02-25 18:17) [0]

Имеется база данных Firebird. Есть некая таблица, пускай с некоторыми заказами. Нужно сделать так, чтобы определенная категория пользователей не имела доступа к этой таблице (тут понятно), другая могла только читать (тоже вроде без проблем), третья могла изменять данные только в определенном поле таблицы, четвертая только в другом поле.

Ну например, самая элементарная структура:

UNIQ_id | NumRequest | DescManager | DescHelper

Поля DescManager и DescHelper - текстовые примечания от соответственно менеджера и службы поддержки (например). И чтобы категория пользователей менеджеры могли добавлять замечания только в свою колонку, а вот поддержка только в свою. Как это все организовать - никак не могу понять.

P.S. Еще хорошо бы разрешить побочный вопрос, как создать такие поля, куда ДОписывать информацию можно было бы, а вот изменять существующую уже нет.

← →
Виталий Панасенко © (2007-02-25 21:53) [1]

grant update и имена полей

← →
Sergey13 © (2007-02-26 08:32) [2]

> [0] Mr. D. (25.02.07 18:17)

Разные способы есть. Например
1. не давать доступ на таблицу напрямую. Давать на представление и набор процедур.
2. разрабатывать структуру таблиц, учитывая необходимое разграничение. Так твою таблицу можно разбить на 2 (вернее на 3 - + справочник типов лиц с доступом) 1- собственно вопросы и 2 - ответы на них.

← →
Виталий Панасенко © (2007-02-26 09:08) [3]

> P.S. Еще хорошо бы разрешить побочный вопрос, как создать
> такие поля, куда ДОписывать информацию можно было бы, а
> вот изменять существующую уже нет.

Даешь разрешение только на INSERT, на UPDATE не даешь.. и все

← →
ЮЮ © (2007-02-26 11:31) [4]

> > такие поля, куда ДОписывать информацию можно было бы,
> а вот изменять существующую уже нет.

Только это уже будут не "поля", а таблица с отношением 0...N (cм. 2).
Ну не в триггере же проверять такое ограничение.

← →
Mr. D. (2007-02-26 16:06) [5]

Блин, не подозревал, что GRAND"ы можно на отдельные поля выдавать в Firebird...

А еще такой вопрос - можно ли как-то получить статус пользователя с БД? Просто хочу написать универсальный клиент, который по нужному логину сам отрубит элементы интерфейса, которые неприменимы к правам залогинившегося пользователя.

← →
Sergey13 © (2007-02-26 16:09) [6]

> [5] Mr. D. (26.02.07 16:06)

Про роли почитай.

← →
Romkin © (2007-02-26 16:28) [7]

Mr. D. (26.02.07 16:06) [5] А также про служебные таблицы, например, про RDB$USER_PRIVILEGES ;)

Про "горизонтальное" и "вертикальное" деление вьюшками чего-то никто не вспомнил.
"Вертикальное" - делаем для каждой роли Updateable view, например, для первой роли select UNIQ_id, DescManager from ttt, для второй select UNIQ_id, DescHelper from ttt. Грант на представление, revoke на таблицу.
"Горизонтальное" - добавить в нужную таблицу колонку с идентификатором группы (если нужно назначать права на группу) или пользователя, навесить на таблицу представление с фильтром по текущему пользователю или группе, полномочия проверять в триггере на вставку или обновление.

← →
Mr. D. (2007-03-06 01:49) [9]

Виталий Панасенко © (26.02.07 9:08) [3]
> P.S. Еще хорошо бы разрешить побочный вопрос, как создать
> такие поля, куда ДОписывать информацию можно было бы, а
> вот изменять существующую уже нет.

Даешь разрешение только на INSERT, на UPDATE не даешь.. и все

да, но примечания могут быть от аж 5 видов пользователей - от менеджеров, от бухгалтерии, от склада и т.д. Я предполагал делать 5 полей с примечаниями от разных групп лиц... Делать 5 таблиц тогда с примечаниями?...

Или примечания объединить в одну таблицу?

> Или примечания объединить в одну таблицу?

Только так. Таблица примечаний в ней ссылка на пользователя (группу пользователей) создавшего примечания.
Иначе обязательно возникнет ситуация когда понадобиться 6 видов пользователей!

Управление доступом к отдельным полям Найти похожие ветки