构建生产版本 - 数据库连接凭证

Question

我们有一个可以为特定环境打包 war 文件的构建，其中我们的所有属性文件都嵌入到存档（war 文件）中。

我们现在即将进行生产。我担心的是代码库需要公开生产数据库密码，尽管不太可能存在生产构建配置文件运行时产生负面影响的风险。

我想到的消除此风险的选项是不在 SVN 中存储生产详细信息，并且：

1. 让管理员覆盖用于连接到数据库的系统属性，或者

2. 让容器管理数据库连接而不是c3p0，这样他们就可以自己管理此配置。

你有什么建议吗？

Answer 1

您绝对不应该将生产数据库用户名和密码放入源代码控制系统中。您的应用程序应该使用 JNDI 获取其数据库连接（例如 DataSource），该连接由生产环境的管理员控制/限制。

例如，如果您的应用程序部署到 Tomcat，则在 tomcat/conf/context.xml 中有以下内容

 <Resource name="jdbc/myDB"
              auth="Container"
              type="javax.sql.DataSource"
              maxActive="20"
              maxIdle="10"
              maxWait="3000"
              username="myusername"
              password="mypassword"
              driverClassName="com.mysql.jdbc.Driver"
              url="jdbc:mysql://myhost:3306/myschema"
              defaultAutoCommit="false"/>

..并且连接是从 java:/comp/env/jdbc/myDB 获取的，无需您的应用程序必须提供用户名或密码。 Tomcat 安装在产品服务器上受到管理员的保护，因此任何没有产品服务器管理员访问权限的人都无法使用它。

Answer 2

在生产中，我赞成根本不将凭据存储在属性文件上的方法。相反，我更喜欢应用程序服务器使用 jndi 提供凭据。

如果您使用的是 Apache Tomcat，请参阅例如其 jndi 参考。

Answer 3

我尝试过在存档中和存档外都拥有属性，并且将它们放在存档外更容易管理此类问题。

需要注意的一些事项：

1. 在可能的情况下，您可以为属性设置默认值，这样，如果未找到该属性，它将使用默认值（例如，使用“localhost”作为默认数据库连接 URL）。
2. 您仍然可以将非生产环境的属性文件与代码一起保留在源代码管理中。

使用这两个策略，开发人员可以负责管理非生产属性文件，因此也可以作为生产管理员的示例。它还将大部分属性集中在源代码控制中，提供了保持集中的一些好处，同时仍然充分解耦属性。

编辑：请注意，JNDI 是一个选项，但从架构上来说，它与外部存储属性文件相同 - 您仍然需要注意这些文件的版本，不要让它们在不同的环境中松散。