对于专用服务器,将连接字符串存储在web.config还是machine.config中更好?每种方法的优缺点是什么?
谢谢
编辑:我担心安全问题,所以问题是哪种方法更安全。
对于专用服务器,将连接字符串存储在web.config还是machine.config中更好?每种方法的优缺点是什么?
谢谢
编辑:我担心安全问题,所以问题是哪种方法更安全。
我更喜欢将连接字符串保存在 machine.config 中。
因为在 DEV、QA 和 PROD 环境中,我的连接字符串是不同的。如果我将它们保存在 web.config 中,我就不能安全地清除目标目录并上传新代码了。否则,我就必须记得部署除了 web.config 之外的所有内容,这会在 web.config 的其他部分发生更改时创建问题。
这取决于你的情况,但当涉及到一些复杂的内容时,将错误的连接字符串放入错误的环境中的风险太大了。我们曾经遇到过测试命中错误的数据库,因为连接字符串被无意间移动了。Machine.config 用于机器特定项目-因此名称如此。它永远不会从一台机器移动到另一台机器。
所以在我的 machine.config 文件中,我有多个连接字符串,例如 blogConnString、forumConnString、projectxConnString 等。我认为这不是混合设置不同站点,而是将机器级别的设置保存在 machine.config 中。
关于安全性的担忧,我认为一旦它们在服务器上,它们就是同样安全的。但是,如果连接字符串在 web.config 中,它通常会出现在源代码控制中、开发人员的桌面上、备份文件中、安装计划、部署集等中。这使得我认为 web.config 不那么安全。
最后,另一种方法是将其保存在完全不同的配置文件中(比如 WebEnvironment.confg),然后在 web.config 中引用它。这个文件将位于一个目录下,这个目录在物理上不属于你的网站,但在虚拟上属于你的网站。更多细节请参见此处。
我会始终选择 web.config,因为这是每个人都期待的地方。把连接字符串存储在不寻常的地方只会给那些必须维护网站的人更多的困难。
补充说明
基于其他信息表明 OP 关心安全问题,而不是一般原因,我添加了以下内容。
我仍然不会将连接字符串存储在 machine.config 中。如果您这样做,任何运行在该计算机上的 .NET 应用程序都可以访问您的连接字符串。
web.config 是受保护的文件。除非您进行错误配置,否则 IIS 不会默认提供它。
如果安全是您的首要关注点,请集中精力锁定数据库和用户权限。Web /机器.config之间的安全差异很小。 Colin的答案是正确的。我本来想投票或在那里发表评论,但我还没有勇气!
这里有很多好的观点。JBrooks的环境最接近我的,但最终我不同意将连接字符串放在Machine.config中。
我同意OJ,但不是他所说的原因。正如JBrooks所说,连接字符串很可能在开发和生产环境中使用不同的凭据。例如,我们的内部网络开发数据库都具有相同的简单凭据,而我们的生产数据库则具有不同的凭据和复杂的密码。因此,有非常好的理由不将连接字符串放在Web/App.config文件中,而是放在目标服务器本地的文件中。我喜欢注册表,但我知道这完全不被支持。显然,Machine.config文件存在是为了提供解决方案。
不,我同意OJ的观点,因为 Machine.config 存在于 .Net 框架中,可以被 Microsoft 更改。但是 Microsoft 对我们生产服务器上的 connectionStrings.config
文件一无所知。该文件由 Web/App.config 文件加载,具体方式如下:
<connectionStrings configSource="path\to\connectionStrings.config"/>
blowdart 提到了加密的重要性 - 这总是一个好主意。但最终,完全保护数据库凭据的唯一方法是定期更改它们。
所有的观点都很好。在我的环境中,数据库是共享的,因此将其存储在 web.config 中会导致冗余。我们在这里使用标准的 SQL 数据库,每个人都可以访问。更喜欢使用单独的配置文件。这样可以实现标准化、安全性,并消除了在部署应用程序时需要更改 web.config 的需求。
从安全角度考虑,您可以将连接字符串存储在自己的加密 .config 文件中,并让您的 web.config 文件引用它。