Visual Studio - 用于部署/源代码控制/源代码共享的用户名/密码管理

发布于 2024-08-29 03:10:23 字数 518 浏览 5 评论 0原文

我想要一种简化的方法,能够在本地运行(工作在多台机器上完成)、部署和提交版本控制,其中敏感信息包括(密码、用户名、端口、主机名) 、数据库名称)会自动缺失(或删除)并根据发生的情况导入?

敏感数据按重要性顺序列出,因此虽然仅密码解决方案很好,但链越靠前越好。另一个好处是,有一个虚拟示例文件,其他人只需填写虚拟文件的缺失部分,就可以在自己的计算机上使用自己的主机来尝试该项目。

对于此功能,我可以选择哪些选项?我考虑过将相关设置添加到本地 machine.config,但随后信息被保存到计算机文件中,而不是在我的用户文档文件中加密的某个位置。此外,这不太适合本地虚拟文件供新程序员即插即用。

我认为最干净的解决方案是项目根目录中的本地 .config 文件,该文件未添加到版本控制中。

如果有一种方法可以对其进行加密,使得服务器计算机是唯一拥有解密文件密钥的计算机(而不是项目能够做到这一点),那么将部署该文件,那就太棒了。然后,我可以将数据存储在源代码管理中,与有兴趣研究该项目的其他人共享源代码,而他们无需获得进行重大更改或查看私人信息所需的实际信息。

I'd like a streamlined methodology behind being able to run locally (work is done on more than one machine), deploy, and commit to version control where the sensitive information up to and including (password, username, port(s), hostnames, database name) are automatically absent(or removed) and imported based on which situation is happening?

The sensitive data was listed in order of importance so while password only solutions are nice, the farther up the chain the better. The other nice to have would be that there's a dummy sample file for someone else to try out the project on their own machine with their own host by just filling in the missing parts of the dummy file.

What are my options to follow for this functionality? I thought about adding the relevant settings to the local machine.config, but then the information is saved out to the machine file instead of somewhere encrypted in my user documents file. Additionally that wouldn't lend itself very well to a local dummy file for newer programmers to plug and play.

What I'm thinking is the cleanest solution is a local .config file in the project root that isn't added to version control.

If there's a way to have it encrypted in such a way that the server machine is the only one with a key to decrypt the file (rather than the project being able to do it) that will be deployed that would be terrific. Then I could have the data stored in source control, share the source with other people interested in studying the project, without them getting the actual information needed to make breaking changes or look at private information.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

生活了然无味 2024-09-05 03:10:23

我们使用多个 .config 文件:一个用于开发,一个用于集成,一个用于 QA,一个用于预生产,一个用于生产。每个文件都标有后缀(例如:.prod)。

这些文件包含软件连接到数据库和服务器所需的所有内容,但生产 .config 文件除外,其中连接字符串、用户和密码已替换为占位符。

当我们向生产团队提供新版本的软件时,我们会提供一个最新但“中性化”的 .config 文件。然后制作团队添加缺失的信息。

我认为加密文件(或信息)不是一个解决方案:然后您会遇到一个新问题:如何隐藏用于加密的密钥...

(注意:我们使用转换为每个文件生成正确的 .config 文件环境。)

We use multiple .config files : one for dev, one for integration, one for QA, one for pre-production and one for production. Each file is labeled with a suffix (eg.: .prod).

The files contain everything the software need to connect to databases and servers, except for the production .config file, where connection strings, users and passwords have been replaced with placeholders.

When we ship a new version of the software to the production team, we ship an up to date but "neutralized" .config file. The production team then add the missing informations.

I think that encrypting the file (or the information) is not a solution : you would then have a new problem : how to hide the keys used for encryption...

(Note : we use transformations to generate the correct .config file for each environment.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文