对于专用服务器，最好将连接字符串存储在web.config或machine.config中吗？每种方法的优点和缺点是什么？
由于
编辑：我担心这里的安全性，所以问题是哪种方法更安全。
答案 0 :(得分：10)
我会一直使用web.config，理由是这是每个人都期望的。通过在不寻常的地方存储连接字符串，给予必须维护网站的人更加困难是毫无意义的。
其他
根据OP对安全方面感兴趣的其他信息，而不是我添加以下内容的一般原因。
我仍然不会在machine.config中存储连接字符串。如果这样做，机器上运行的任何.NET应用程序都可以访问您的连接字符串。
web.config是受保护的文件。默认情况下，IIS不会提供它，除非你做错了配置它。
答案 1 :(得分：9)
我更喜欢在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.
答案 2 :(得分：5)
我个人来说，永远不会将我的连接字符串存储在我的machine.config文件中，只能存储在web.config中。
你说它是一个专用服务器，但是这个服务器专用于单个Web应用程序吗？ 如果没有，您现在有一个文件（machine.config）可以有效地共享多个（可能是不相关的）Web应用程序的配置数据。根据这些应用程序的数量，如果您需要将它们移动到另一台服务器，使用machine.config可能会非常混乱。
即使服务器 专用于单个Web应用程序，您也可能正在其他计算机上执行开发和测试。由于machine.config通常不是包含在ASP.NET Web应用程序项目的文件集中的文件，因此您可能不得不竭尽全力将machine.config部署到各个dev / test中。 /生产机器，并确保其中的其他（非连接字符串）相关配置对于该机器是正确的。
使用web.config存储数据库连接字符串具有完全的逻辑意义，并且几乎所有ASP.NET开发人员都完全可以预期，即使您有多个应用程序将在完全相同的数据库服务器上使用完全相同的数据库。将此配置保存在每个应用程序的web.config中允许每个应用程序更加自包含，而不依赖于其他一些“外部”文件。
我通常查看machine.config和框架本身使用的东西，它属于一台机器并且特定于该机器。我很少自己去接触它。我将web.config视为一个文件，它是您的Web应用程序项目的一部分，并在该项目移动时“随处移动”并部署到不同的计算机上。
此外，不要忘记，通过重新定义特定应用程序的web.config文件中的某些配置元素，可以在每个应用程序的基础上“覆盖”machine.config中定义的许多内容。
当然，编辑/更改machine.config文件有一些正当理由（例如，Web场中的多个Web服务器可能需要像machine.config中的加密/解密密钥一样进行同步），但是，我不相信数据库连接字符串是其中一个正当理由。
答案 3 :(得分：3)
如果您主要关注安全性，请专注于锁定数据库和用户权限。 web / machine .config之间的安全性差异很小。科林的回答是正确的。我已经在那里投票或评论但我还没有moxie！
答案 4 :(得分：1)
这里有很多好处。 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提出了关于加密的观点 - 总是一个好主意。但最终，完全保护数据库凭据的唯一方法是定期更改它们。
答案 5 :(得分：0)
安全方面，您可以考虑将连接字符串存储在您自己的web.config文件可以引用的加密.config文件中。
答案 6 :(得分：0)