2maxapet

авторЯ сделал так: написал класс, статическим членом которого является строка ConnectionStr, описывающая подключение к БД. И теперь, когда мне нужно подключение, я использую эту строку CDBConnection.ConnectionStr при создании подключения. И изменить легко - только в одном месте

Только 2 замечания:

1.При этом или весь проект или отдельную DLL придётся перекомпилировать и передеплоить на Web сервере.

2.При компиляции стринговые литералы остаются как есть - если Вашу DLL открыть в Notepad, то можно прочесть Connection string

2maxapet

А, так у Вас это

"server=.;Integrated Security=SSPI;Initial Catalog=test"

ну тогда и пусть видно, но вот в случае сиквельной аутентикации это проблема. Я начинал свой первый проект на ASP.NET 1.0 и по ряду причин (юзера разбросаны по многим домейнам и нет желания либо создавать траст либо NT domain accounts в нашем домейне) мы используем Forms authentication с Anonymous access на IIS и без identity impersonation. И если мне не изменяет память, единственным способом заставить работать aspnet_wp.exe под домейн аккаунтом для версии 1.0 было в явном виде прописать этот аккаунт и его пассворд в Machine.config. Microsoft же тогда советовал не делать этого, а продолжать пользоваться ASPNET локальным аккаунтом, а для коннекта к серверу БД создавать одноимённый локальный аккаунт на нём, добавить его в сиквел и вручную синхронизировать пароли. А у нас аудит требует чтобы все пароли раз в месяц менялись. Поэтому мы это дело похерили и создали один сиквельный аккаунт который хранится в зашифрованном виде (Win32 CryptoAPI) в registry на Web сервере. На Web сервере же размещена public assembly которая читает и расшифровывает коннекшн стринг. Поскольку этот сиквельный аккаунт и пасворд к нему хотя и зашифрованные, храняться за пределами сиквела, там где они хпанятся раз в сутки срабатвает cancel application которая от греха подальше меняет пассворд случайным образом и обновляет зашифрованную строку в registry. Дальше, по этому аккаунту доступ разрешён только к одной базе данных, где хранятся только искусственные аккаунты для Forms authentication и hash'ы пассвордов за последние 12 месяцев - юзверя обязаны их менять каждые 30 дней тож, при этом нельзя повторять пассворд в течении года. Так что если даже этот аккаунт будет скомпрометирован, это большая неприятность но не катастрофа. Доступ собственно к базам данных осуществляется через другие сиквельные аккаунты, которые также зашифрованны на CryptoAPI, но храняться уже внутри сиквела по одному на базу чтобы обеспечить разумный коннекш пуллинг и минимизировать ущерб в случае компрометации одного из них. Цель такой архитектуры - возможность менять пассворды и этих аккаунтов не прерывая ни на минуту 7/24 режим работы web приложений. Конечно, эта схема не идеальна, на ASP.NET 1.1 вроде можно гонять aspnet_wp.exe под домейн аккаунтом и криптовать пассворд, но привыкли уже к тому что есть, да и на каждый Microsoft'овский чих не наздравствуешься.

Это что, тонкий сарказм?