Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, Ziaw, Вы писали:

Z>>Нужно везде проверять может ли пользователь иметь доступ к конкретным данным. Если может — показываем, если нет — нет. Например, если тебе нужно сделать какие-то приватные строки в таблице, сделай там поле OwnerID и ко всем запросам добавляй and (OwnerID = @CurrentUserId).
DOO>Ну дак ты все-таки объяснишь, почему надо обязательно изобретать свой велосипед, собирая по дороге все шишки до этого набитые производителями ОС и СУБД?


Если ты объяснишь мне зачем тут что-то изобретать.

База дает:

Table level crud security — приложение все равно должно знать все эти правила, чтобы UI мог дисаблить/скрывать ненужные кнопки, если приложение и так умеет делать такие проверки, зачем нам их тащить еще на уровень БД? Какой смысл поддерживать две одинаковые схемы безопасности и там и там и не допускать их рассогласовывания. Зачем удваивать вероятность ошибок определенного класса? При развитии/поддержке работающей системы хватает забот и без этого.

Column level security — в моем случае перечисление в запросе только тех колонок которые доступны пользователю. Это придется делать и в твоем случае тоже.

Row level security — в моем случае обычный предикат к запросам, в твоем случае такой же предикат, только он настривается в БД. Только вот я у себя могу в любой момент отключить этот предикат из кода приложения, а у тебя нужны не очень простые приседания.

Итак, сухой остаток: единственный плюс авторизации БД — нельзя забыть подставить предикаты безопасности в RLS. Это реализуемо и в коде приложения, например через linq.