开源项目如何做到不泄露配置文件中的密码信息？

示例配置文件我们这边用的是 .env.defaults ，
线上读取的是 .env ，
.env 加入到 .gitignore 里不进版本控制。

.env 文件

开发和生产环境密码不是环境变量传入的吗？

还有，你知道 JetBrains 开源许可是只可用于开发开源软件的是吧？如果你在开源项目之外还有别的项目，它们是不能用开源许可证的。

类似这样 只提交 git 版本的,里面配置为空或者默认的,dev 版本填实际,开发时候切一下就行

环境变量才是王道

环境变量，github 还可以把环境变量加到 Repository secrets 里

Jasypt 加密。

springboot： 在 resources 下创建 application-local.yml ，然后启动加上参数：spring.profiles.active=local
还需要在.gitignore 文件中添加：*-local.yml

@zjb861107 学习了，有一个疑问就是这个环境变量指的是什么呢？是配置系统的环境变量，然后在 spring boot 的配置文件获取系统环境变量吗？

配置启动参数就可以了

密码用随机生成的 key 对称加密得到密文，之后把密文存进 repo 里，用 GitHub secret 存 key 。部署时在 workflow 里通过 secret 得到 key ，再解密密文得到密码。

提醒下，Copilot 是流行的开源项目的主要维护者免费。
就算起了一个开源项目，如果不够流行的话也是不免费的。

环境变量吧
dotenv

@undownding 我之前的做法类似，不过我配置复制一份去掉敏感信息，然后命名加上.bak ，把真实的配置文件加入.gitignore ，这样别人拉下开的时候，就需要把.bak 那个文件后缀去掉，然后填写配置使用

@msg7086 看了楼上的回答学习了，当然是用于开源项目

@licoycn 学习了

注意 commit 历史也不能包含敏感配置信息，否则可以被 checkout 出来。

只写过业务代码，没在生产环境玩过服务器运维的小盆友（也不排除有很多老手甚至所谓架构师）可能潜意识里默认认为配置文件“只能”或者“应该”从项目路径结构（当前目录或者下面的子目录）读取，所以在这个问题上会犯难。其实哪有这么愁呢？
方法一，程序里指定从 /etc/<my_project>/<some_item>.conf 这样的 site-wide global path 里读取配置，开发机和生产环境各写各的配置，互不影响，提交的代码里根本不包含配置文件，而且做部署的时候也不会覆盖现有的配置文件。缺点是如果配置文件语法、语义有版本变化，需要生产环境的运维人员配合做升级。
方法二，做两个不同的 profile ，但都是从项目内部路径读取配置。开发机用开发的 profile ，部署到生产环境用生产的 profile 构建打包。两个 profile 的配置文件加入.gitignore 确保不会提交。缺点是每次在新的开发机上 clone 出来需要自己准备配置文件。
方法三，做两个不同的 profile 。开发机用开发的 profile ，从项目内部路径读取配置。部署到生产环境用生产的 profile 构建打包，不打入配置文件，而是从 site-wide global path 里读取配置。开发 profile 的配置文件加入.gitignore 确保不会提交（其实提交了也无所谓）。集一和二的部分优缺点。
当然，做不同 profile 也有多种实现方式。一般 Java 项目是在构建时区分，某些脚本语言的项目往往在运行时通过读取环境变量或者命令行参数来区分。只要能分开，都不是大问题。

只写过业务代码没在生产环境玩过服务器运维但是对这个问题又困惑并且愿意较真的小盆友们还是认真玩玩服务器。比如用 Linux 的，至少了解文件系统的各部分，知道发行版打包好的基础软件是怎么使用文系统里不同目录结构的，File-system Hierarchy Standard 是什么。虽然发行版打包好的基础软件的惯例通常不太适合 100%照搬到业务系统上，但有很大的借鉴价值，会让你们的系统部署跟运维老司机的对接更流畅。

方法四，加一个命令行参数，用于指定从哪里读取配置文件。默认是从项目内部路径，可以指定覆盖。服务器上部署时，就在 systemd unit 或者其它启动机制里指定。

我自己做的小项目或者要供应商做的大项目里主要用方法三和四。

参数少的话用环境变量吧

个人目前开发和部署使用的方法。
- 不用 spring profile 。profile 的方式感觉更适合不同 **开发** 环境的切换，生产环境的配置不应该用这个方法。
- 不用 git ignore 或者本地备份修改的方式。会忘，真的会忘，总有人不小心给提交了。
- 不用服务器环境变量。这个配置起来太繁琐，尤其是一台机器跑多个项目。
- spring boot 项目在 IDEA 中配置 override configuration properties ，不会被不小心提交到 git 。
- 如果服务器直接用 java 运行（奇怪的 windows 服务器，懒得迁移了），将需要修改的属性值放在 config/application.properties 文件中，不需要修改的不用放，这样可以一眼看出来修改了哪些。
- 如果服务器使用 docker 运行，跟上面一条一样，把配置文件映射到 container 内的 config 目录下即可。

跟团队项目如何做到不把个人配置提交到中央仓库，是一样的原理：使用可覆盖的配置体系，本地配置覆盖默认配置；中央仓库只提交默认配置。

Spring Boot 的配置文件体系 https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config ，随便玩都行。最简单的：application.yml 弄一句 spring.profiles.active=local ，然后示例 /默认配置都放到 application.yml 一起提交；.gitignore 里面加一条*-local.yml ，然后把 .gitignore 提交了（很重要）；本地直接源码 application.yml 旁边放一个 applicaltion-loacl.yml ，生产环境就 jar 的旁边放 application-local.yml ，local 当中只填写非默认的配置，这样即不用担心提交污染默认配置（或者泄露个人配置），也能让定制配置的内容更简洁。

账号密码写到系统环境变量里，就算配置文件不小心公开了也没事

使用环境变量注入，dev 里写死，prod 直接从环境变量拿

.gitignore:
config.txt
只保存 default_config.txt

真的是后端开发？入门都知道密码密钥信息要写到 env 里吧。。。

环境变量