hey_123ну скажем у нас трехзвенка обычно реализуется самым элементарным образом - просто вызов wcf сервиса иви вебсервиса который просто тупо транслирует вызов дальше. Т.е. если потенциальные дырки и есть, то только в самих стандартных компонентах. "Свои" баги тут я даже не знаю как посадить при всем желании :)
Ну, совсем прямая трансляция не нуждается в компонентах, ей достаточно файла конфигурации (что принимать и во что транслировать). Но всё-таки пусть тупой код, но пишется руками. Та же авторизация - сервис как-то хранит, как-то проверяет права, прежде чем транслировать вызов. Хотя бы вызовы процедур пишутся. Стандартные компоненты - с ними, собственно, как и с СУБД, желающих найти дырки больше.
Я, правда, вообще не склонен считать "звеном" софтину, выполняющую роль "драйвера". Имхо понятие "звено" таки означает наличие некоторой логики, некоторого умного кода приложения.
hey_123а вот тут не думаю, что это есть достоинство трехзвенки как таковой, мне ничто не мешает делать любые проверки перед вызовом БД в самом клиенте (просто другом слое)
В клиенте-то делать можно, но меньше толку - таки легче идти к базе мимо клиента или с использованием самописного клиента. Трёхзвенка таки позволяет куда лучше забаррикадировать доступ к СУБД и тем заставить ходить через "проверяемый" интерфейс.
hey_123в sql server можно создать процедуру, которая будет выполняться в контексте другого пользователя....
Мм.. боюсь, либо это не то, о чём я спрашивал, либо не то, чем стоит гордиться :) Это вроде как совершенно обычная фича пятнадцатилетней давности, никак не связанная с возможностью динамически переключать внутри соединения контекст безопасности. Я имею в виду вот что (в оракловых терминах)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
create user MyApplication;
create table MyApplication.MyTable;
create user Sasha;
create user Vasya;
create user Petya;
create procedure MyApplication.InsertIntoMyTable authid definer;
grant execute on MyApplication.InsertIntoMyTable to Sasha;
create procedure MyApplication.InsertIntoMyTable2 authid current_id;
grant execute on MyApplication.InsertIntoMyTable2 to Vasya, Petya;
grant insert on MyApplication.MyTable to Vasya;
Теперь в рамках какой-либо конкретной сессии пула соединений может быть выполнена следующая последовательность действий со следующими результатами:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
connect Sasha;
insert into MyApplication.MyTable; ERROR! Cannot insert into MyApplication.MyTable
exec MyApplication.InsertIntoMyTable; -- Success
exec MyApplication.InsertIntoMyTable2; ERROR! Cannot execute MyApplication.InsertIntoMyTable2
connect Vasya;
insert into MyApplication.MyTable; -- Success
exec MyApplication.InsertIntoMyTable; ERROR! Cannot execute MyApplication.InsertIntoMyTable
exec MyApplication.InsertIntoMyTable2; -- Success
connect Petya;
insert into MyApplication.MyTable; ERROR! Cannot insert into MyApplication.MyTable
exec MyApplication.InsertIntoMyTable; ERROR! Cannot execute MyApplication.InsertIntoMyTable
exec MyApplication.InsertIntoMyTable2; ERROR! Cannot insert into MyApplication.MyTable
Подчеркну: это делается в рамках одной сессии, то есть сервер способен использовать пул соединений, выполняя блоки команд то от Саши, то от Пети, то от Васи, и используя при этом настроенную на сервере безопасность для каждого из них.
