SVN中配置文件的存储策略
我们的大部分 C# 项目配置都保存在 *.ini 文件中。主要这些文件保存 许多部分影响程序行为的各个方面。但除了常规配置数据之外，某些部分也很容易受到攻击，例如数据库连接字符串或服务器密码。我们尝试以以下形式保留此部分：
[Database]
user=testuser
database=testdb
password=
但是当开发人员测试应用程序时，他必须填写配置才能启动应用程序。某些密码被提交到版本控制中是很常见的。 由于这些文件对于应用程序是必不可少的，因此不能包含在 .svnignore 中。 可能我正在寻找的是某种脚本（也许在 powershell 中）。这将扫描所有 *.ini 文件并删除所有密码。最有趣的解决方案是添加一些外部密码存储，可用于对 *.ini 文件中的密码进行编码和解码。
The majority of our C# projects configuration is kept in *.ini files. Mainly these files hold
many sections affecting all aspects of programs behaviour. But besides of regular configuration data some of sections are vulnerable like db connection string or server password. We try to keep this sections in following forms:
[Database]
user=testuser
database=testdb
password=
But when developer is testing application he must fill the config in order to start application. It is quite common that some of the passwords are commited into version control.
Because these files are indispensable for application they cannot be included in .svnignore.
Probably what I'm looking for is some kind of script (maybe in powershell). That would scan all *.ini files and erase all passwords. The most interesting solution would be adding some external password storage that can be used both to encode and decode passwords in *.ini files.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我总是推动在 subversion 中存储配置模板文件，而不是实际的配置文件。因此，如果配置文件是“config.ini”，那么我将签入填充有非工作示例数据的“config.ini.template”。
然后，为了防止多个开发人员签入各自的“config.ini”文件，我将实际的配置文件名添加到 svn:ignore 属性列表中。
这迫使开发人员复制文件并根据其环境进行适当的修改，但通过不强迫他们找出需要存在的字段来简化该任务的工作。如果有时间，您甚至可以在模板文件中嵌入注释，以简化某些配置选项的含义。
在文件的顶部，包括如何使用模板配置系统的说明，其内容应如下所示：
您明白了......
如果您在人员签入时遇到问题（或认为您可能遇到问题）他们的配置选项超过 config.ini.template 文件，那么我建议在模板文件上使用“svn lock”。然而，在适当的警告下，我从未发现有必要。
I always push to store configuration template files in subversion, but not actual configuration files. So if the configuration file is "config.ini" then I'll check in a "config.ini.template" populated with non-working sample data.
Then to prevent multiple developers from checking in their individual "config.ini" files, I'll add the actual configation file name to the svn:ignore properties list.
This forces the developer to copy the file and modify it appropriately for their environment, but eases the work of that task by not forcing them to find out which fields need to be present. If you have the time, you can even embed comments into the template file to simplify the meanings of some of the configuration options.
At the top of the file, include the directions of how to configure the system using the template, which should read something like:
You get the idea....
If you have problems (or think you might have problems) with people checking in their configuration options over the config.ini.template file, then I'd recommend using "svn lock" on the template file. However, with the appropriate warning, I've never found it necessary.
我不会回答你的问题，而是推荐一种不同的方法，假设现在改变相关设计还为时不晚。
您不应将密码与其他密码存储在同一文件中。除了常规配置文件之外，让应用程序读取专用密码文件（或从密码存储服务检索密码）。这不仅是关于不在 svn 中存储密码，而且是关于不要让密码暴露于肩窥、当有人寻求非工作配置的帮助时意外邮寄或发布等。
I'll not answer your question and instead recommend a different approach, assuming it's not too late to change the relevant design.
You should not store passwords in the same files as the rest. Have the application read a dedicated password file (or retrieve the password from a password storage service) in addition to the regular configuration file. This is not just about not storing passwords in svn, but also about not having passwords exposed to shoulder surfing, accidentally mailed or posted when someone asks for help with a non-working configuration, etc.