asp.net - 在 machine.config 中存储连接字符串与在 web.config 中存储它们

Question

对于专用服务器，将连接字符串存储在 web.config 或 machine.config 中更好吗？每种方法的优缺点是什么？

谢谢

编辑：我担心这里的安全性，所以问题是哪种方法更安全。

Answer 1

我总是会使用 web.config，因为这是每个人都希望它出现的地方。通过将连接字符串存储在不寻常的地方，给必须维护网站的人带来更多困难是没有意义的。

额外的

基于 OP 对安全方面感兴趣的其他信息，而不是一般原因，我添加了以下内容。

我仍然不会在 machine.config 中存储连接字符串。如果您这样做，机器上运行的任何 .NET 应用程序都可以访问您的连接字符串。

web.config 是一个受保护的文件。默认情况下，IIS 不会提供它，除非您对它进行了错误配置。

Answer 2

我更喜欢将连接字符串保留在 machine.config 中。

我的连接字符串在 DEV、QA 和 PROD 环境之间是不同的，如果我将它们保存在 web.config 中，我就无法安全地删除我的目标目录并复制新代码。或者我必须记住部署除 web.config 之外的所有内容，这会在 web.config 的其他部分发生更改时产生问题。

这取决于您的情况，但是当它变得有点复杂时，在错误的环境中使用错误的连接字符串的风险太大了。实际上，我们遇到过由于连接字符串被无意移动而导致测试命中错误数据库的情况。Machine.config 用于机器特定的项目 - 因此名称。它永远不会在机器之间移动。

因此，在我的 machine.config 中，我有多个连接字符串，如 blogConnString、forumConnString、projectxConnString 等。我不考虑针对不同站点的这种混合设置，我认为它在 macing.config 中保持机器级别设置。

您担心安全性，我认为一旦它们放在盒子上，它们就同样安全了。但是，如果连接字符串在 web.config 中，它通常会出现在源代码控制、开发人员的办公桌、备份文件、安装计划、部署集等中。这使得 web.config 对我来说不太安全。

最后，另一种方法是将它放在一个完全不同的配置文件中（比如 WebEnvironment.confg），然后在你的 web.config 中引用它。该文件将位于实际上不在您的网站下但实际上在您的网站下的目录中。更多细节在这里。

Answer 3

我个人永远不会将连接字符串存储在 machine.config 文件中，只会存储在 web.config 中。

你说它是一个专用服务器，但这个服务器是专用于单个 Web 应用程序的吗？
如果没有，您现在拥有一个文件 (machine.config)，它可以有效地共享多个（可能不相关的）Web 应用程序的配置数据。根据这些应用程序的数量，如果您需要将它们移动到另一台服务器，使用 machine.config 可能会变得非常混乱。

即使服务器专用于单个 Web 应用程序，您也可能会在其他机器上执行开发和测试。由于 machine.config 通常不是包含在 ASP.NET Web 应用程序项目的文件集中的文件，因此您可能不得不特意将 machine.config 部署到各种开发/测试中的每一个/production 机器，并确保其中的其他（非连接字符串）相关配置对于该机器是正确的。

使用 web.config 存储数据库连接字符串非常合乎逻辑，并且几乎所有 ASP.NET 开发人员都完全期望，即使您有多个应用程序将在完全相同的数据库服务器上使用完全相同的数据库。将此配置保存在每个应用程序的 web.config 中可以使每个应用程序更加独立，并且不依赖于其他一些“外部”文件。

我通常查看 machine.config 和框架本身使用的东西，它属于一台机器并且特定于该机器。我很少亲自进去触摸它。我将 web.config 视为一个文件，它是您的 Web 应用程序项目的一部分，并且随着该项目的移动和部署到不同的机器上“移动”。

另外，不要忘记，通过在特定应用程序的 web.config 文件中重新定义某些配置元素，可以在每个应用程序的基础上“覆盖” machine.config 中定义的许多内容。

当然，编辑/更改您的 machine.config 文件有一些正当理由（例如，网络场中的多个 Web 服务器可能需要将 machine.config 中的加密/解密密钥等内容同步），但是，我不要相信数据库连接字符串是这些正当理由之一。

Answer 4

如果安全是您最关心的问题，请集中精力锁定数据库和用户权限。web/machine .config 之间的安全差异很小。科林的回答是正确的。我会在那里投票或发表评论，但我还没有 moxie！

Answer 5

这里有很多优点。JBrooks的环境最接近我的，但最后我不同意将连接字符串放在 Machine.config 中。

我同意OJ，但不是因为他在这里引用的原因。我要指出，正如JBrooks所说，连接字符串很可能在开发和生产环境中使用不同的凭据。例如，我们的 Intranet 开发数据库都具有相同的一组简单凭据，而我们的生产数据库则具有不同的凭据和复杂的密码。因此，有很好的理由不将连接字符串放在 Web/App.config 文件中，而是放在目标服务器的本地文件中。我自己喜欢注册表，但我知道这根本不受支持。显然，Machine.config 文件可以提供解决方案。

不，我同意OJ，因为 Machine.config 位于 .Net 框架中，并且可以由 Microsoft 更改。connectionStrings.config但微软对我们生产服务器上的文件一无所知。此文件由 Web/App.config 文件加载：

<connectionStrings configSource="path\to\connectionStrings.config"/>

blowdart提出了关于加密的观点——总是一个好主意。但最终，完全保护您的数据库凭据的唯一方法是定期更改它们。

Answer 6

安全方面，您可以考虑将连接字符串存储在您的 web.config 文件将引用的加密 .config 文件中。

Answer 7

所有优点。在我的环境中，数据库是共享的，因此存储在 web.config 中会强制冗余。我们在这里使用每个人都可以访问的标准 SQL 数据库。最好使用单独的配置文件。这允许标准化、安全性和消除在部署应用程序时更改 web.config 的需要。