Для выделенного сервера лучше хранить строку подключения в файле web.config или machine.config? каковы преимущества и недостатки каждого подхода?Сохранение строк подключения в файле machine.config и их сохранение в web.config
Благодаря
Edit: Я беспокоюсь о безопасности здесь, поэтому, вопрос о том, какой подход является более безопасным.
Я всегда бывал с web.config на том основании, что именно там все и ожидали. Нет смысла давать человеку, которому больше нужно поддерживать веб-сайт, путем хранения строк подключения в необычном месте.
ДОПОЛНИТЕЛЬНЫЕ
на основе дополнительной информации о том, что ОП заинтересован в аспекте безопасности, а не и общая причина, я добавил следующее.
Я все еще не хранил строки подключения в machine.config. Если вы это сделаете, любое приложение .NET, работающее на компьютере, имеет доступ к вашим строкам подключения.
web.config является защищенным файлом. IIS не будет работать по умолчанию, если вы не сделаете что-то, чтобы его неправильно настроить.
Согласен. Будь проще. И не только для других, для себя тоже. – serialhobbyist
На самом деле я собираюсь сам сохранить сайт, так что это не проблема. –
В моей рекомендации не упоминается, кто является сопровождающим. Даже если это вы, моя рекомендация все еще стоит. Держите вещи простыми. Через 6 месяцев вы, возможно, забыли. –
Я лично не буду хранить строки подключения в файле machine.config, только когда-либо в файле web.config.
Вы говорите, что это выделенный сервер, но этот сервер предназначен для одного веб-приложения?
Если нет, у вас есть один файл (machine.config), который эффективно использует данные конфигурации для нескольких (возможно, не связанных) веб-приложений. В зависимости от количества этих приложений, и если вам когда-либо понадобилось переместить их на другой сервер, использование machine.config может стать очень грязным.
Даже если сервер -, предназначенный для одного веб-приложения, вы, вероятно, будете выполнять свою разработку и тестирование на других машинах. Поскольку файл machine.config обычно не является файлом, включенным в набор файлов проекта веб-приложения ASP.NET, вам, вероятно, придется уклониться от развертывания machine.config для каждого из различных dev/test/production, и убедитесь, что другая (не соединительная строка) соответствующая конфигурация внутри них правильная для этой машины.
Использование web.config для хранения строк подключения к базе данных имеет совершенно логичный смысл и полностью ожидается почти всеми разработчиками ASP.NET, даже если у вас есть несколько приложений, которые будут использовать ту же самую базу данных на том же сервере базы данных. Сохранение этой конфигурации в web.config каждого приложения позволяет каждому из этих приложений быть более автономным и не зависит от какого-либо другого «внешнего» файла.
Обычно я смотрю файл machine.config и что-то, что использует сам фреймворк, и он принадлежит на машине и специфичен для этой машины. Я очень редко вхожу и сам касаюсь. Я рассматриваю web.config как файл, который является частью и частью вашего проекта веб-приложений и «перемещается» с этим проектом при его перемещении и развертывается на разных машинах.
Кроме того, не забывайте, что многое из того, что определено в файле machine.config, можно переопределить для каждого приложения, переопределив некоторые элементы конфигурации в файле web.config конкретного приложения.
Конечно, есть несколько веских причин для редактирования/изменения файла machine.config (например, для нескольких веб-серверов в веб-ферме, возможно, потребуется синхронизировать ключи шифрования/дешифрования в файле machine.config) , однако, я не верю, что строки подключения к базе данных являются одной из тех веских причин.
Спасибо за подробный ответ, это одно веб-приложение. –
Крейг - Я понимаю вашу точку зрения, но я думаю, что вам не хватает реальности поддержки больших наборов приложений, которые используют конфигурацию сети или приложения. У нас есть 25 проектов на некоторых наших серверах, которые содержат одну и ту же строку подключения к базе данных. Нам придется вручную обновлять все строки соединений во всех проектах, чтобы переместить наш сервер БД на новое имя хоста. Если бы они находились в конфигурации машины, мы могли бы изменить их в одном месте. – lukevp
@lukevp Для вашей конкретной ситуации, которая несколько необычна, я могу понять, желая сохранить строку соединения в файле machine.config, чтобы избежать повторения той же строки соединения в 25 разных файлах web.config. Я бы предположил, что большинство людей, у которых есть 25 приложений на одном сервере, вероятно, будут иметь много разных строк соединения, в основном уникальных для каждого приложения. – CraigTP
безопасности, вы можете посмотреть на свои строки подключения, там есть собственный зашифрованный файл .config, к которому будет привязан ваш файл web.config.
Вы можете шифровать только разделы web.config. Вам не нужно создавать совершенно новый файл. –
Мне обычно легче управлять, если они находятся в отдельном файле. особенно если у вас есть множество строк подключения. – MakkyNZ
Если безопасность является вашей основной задачей, сконцентрируйтесь на блокировке базы данных и разрешений пользователя. Разница в безопасности между web/машиной .config минимальна. Ответ Колина правильный. Я бы проголосовал или прокомментировал, но у меня еще нет мокси.
Действительно - Безопасность - многослойный зверь.Вы должны сделать все возможное, чтобы блокировать биты под поверхностью, а также то, что на поверхности, чтобы быть уверенным. –
Я предпочитаю хранить строки подключения в файле machine.config.
Мои строки подключения различаются между средами DEV, QA и PROD, и если бы я сохранил их в файле web.config, я не мог безопасно снести мой целевой каталог и скопировать новый код. Или мне придется помнить, что нужно развернуть все, кроме web.config, это создает проблемы при изменении других частей web.config.
Это зависит от вашей ситуации, но когда он немного усложняется, риск неправильной строки подключения в неправильной среде слишком велик. На самом деле у нас были ситуации, когда тестирование попадало в неправильные базы данных, потому что строка подключения была непреднамеренно перемещена. Machine.config используется для конкретных машин - таким образом, имя. Он никогда не перемещается с машины на машину.
Так что в моем machine.config у меня есть несколько строк подключения, таких как blogConnString, forumConnString, projectxConnString и т. Д. Я не рассматриваю этот параметр смешивания для разных сайтов, я считаю, что он поддерживает настройку уровня машины в maching.config.
Вы беспокоились о безопасности, я думаю, что когда они находятся на коробке, они одинаково защищены. Но если строка подключения находится в файле web.config, она обычно заканчивается в системе управления версиями, столах разработчиков, в файлах резервного копирования, в планах установки, наборах развертывания и т. Д. Это делает способ web.config менее безопасным для меня.
Наконец, другой подход заключается в том, чтобы иметь его в совершенно другом файле конфигурации (например, WebEnvironment.confg), который затем ссылается на ваш web.config. Этот файл будет находиться в директории, которая не находится под вашим веб-сайтом, но находится практически под вашим сайтом. Более подробная информация HERE.
Извините, но я полностью не согласен с этим. Конфигурация машины выполняется в файле machine.config, а не в конфигурации приложения. Строки подключения к базе данных специфичны для приложений, а не для конкретной машины. –
Если вы устанавливаете Windows сейчас, вы получите строку подключения по умолчанию в machine.config - LocalSqlServer. Это значение конфигурации машины для локального SQL Express. У меня есть конфигурация машины для моего блога, моего основного сайта и т. Д. Как разработчик, это просто делает его настолько легким. – JBrooks
Каждому принадлежит. Но я не вижу, чтобы «MS сделать это, чтобы все было в порядке», как хорошее оправдание. Я потерял счет ужасных примеров кода, которые были на веб-сайте MSDN. Просто потому, что они создали его, это не значит, что их предложения о том, как его использовать, являются лучшими. Я также не обращаю внимания на «упрощение жизни для разработчика», но опять же это личное предпочтение. Это не обо мне, это все о программном обеспечении. –
Здесь есть много хороших моментов. Окружающая среда JBrooks ближе всего к моей, но в конце концов, я не согласен с установкой строк соединения в Machine.config.
Я согласен с OJ, но не потому, что он цитирует здесь. Я хотел бы указать, как сказал JBrooks, строки подключения, скорее всего, будут использовать разные учетные данные в средах разработки и производства. Например, наши базы данных разработки интрасети имеют один и тот же набор простых учетных данных, в то время как наши производственные базы данных имеют разные учетные данные со сложными паролями. Поэтому есть очень веские причины не помещать строки подключения в файл Web/App.config, а скорее в файл, локальный на целевой сервер. Мне нравится реестр, но я знаю, что это совсем не поддерживается. Очевидно, что файл Machine.config должен предоставить решение.
Нет, я согласен с OJ, потому что Machine.config находится в .NET Framework и может быть изменен Microsoft. Но Microsoft ничего не знает о файле connectionStrings.config на наших производственных серверах. Этот файл загружается через Web/App.конфигурационные файлы с:
<connectionStrings configSource="path\to\connectionStrings.config"/>
blowdart сделал пункт о шифровании - всегда хорошая идея. Но в конце концов, единственный способ полностью защитить ваши учетные данные базы данных - это периодически менять их.
все хорошие моменты. В моей среде базы данных разделяются, поэтому сохранение в файле web.config избыточности. Здесь мы используем стандартные базы данных SQL, к которым каждый обращается. Предпочтительным является отдельный файл конфигурации. Это позволяет стандартизировать, защищать и устранять необходимость изменения web.config при развертывании приложения.
В любом месте, которое вы должны рассмотреть, зашифруйте его (хотя, если вы используете надежные соединения, я бы не стал так беспокоиться). Для этого сейчас есть удобный инструмент: http://somewebguy.wordpress.com/2009/07/16/encrypt-your-web-config-please/ – blowdart
Ссылка в комментарии выше мертва; теперь на http://hugoware.net/blog/encrypt-your-web-config-please –