В принципе, тот же самый результат можно получить и
другими способами. Например, вот такое выражение SQL отражает те же самые
правила:
|
case
when ReportDate >
DateAdd(month, GetDate(), 1) then false
when ReportDate >
DateAdd(month, GetDate(), 6) then
IsUserInRole('senior_analyst')
else
IsUserInRole('junior_analyst')
end
|
Однако здесь проследить логику уже труднее, и ситуация
станет еще хуже, когда в рассмотрение войдут другие поля таблицы. Поэтому мы
ограничим возможные предикаты вот такой структурой:
|
(IsUserInRole(<role1>) AND <role1_restrictions>)
OR
(IsUserInRole(<role2>) AND <role2_restrictions>)
OR ...
(IsUserInRole(<roleN>) AND <roleN_restrictions>)
|
Таким образом, предикат определяет для каждой группы
пользователей требования, которым должна удовлетворять строка таблицы, чтобы
доступ к ней был разрешен.
Лишение доступа
Форма предиката безопасности, рассмотренная выше, подразумевает «пессимистичный» режим, т.е. доступ к данным имеют только те
категории пользователей, которые явно перечислены в предикате.
|
ПРИМЕЧАНИЕ
Строго говоря, если мы не опишем ни
одного правила, то предикат будет пустым и доступ получат все пользователи.
Однако выдача таким способом доступа хотя бы одной роли автоматически лишит
доступа всех остальных пользователей. Решить эту проблему можно раз и
навсегда - введя дополнительный член ...OR FALSE в предикат безопасности.
Однако подобный вырожденный случай нетрудно обработать специальным образом, и
далее в тексте везде предполагается наличие в списке доступа хотя бы одного
явного разрешения.
|
Иногда удобнее описывать правила безопасности в
терминах «оптимистичного» режима, т.е. лишить доступа только некоторое
множество пользователей. В этом случае предикат приобретет такой вид:
Главная