Question

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

我们现在正要为生产而建造。我担心的是代码库需要公开生产数据库密码，尽管不太可能存在生产构建配置文件可能带来负面影响的风险。

我想要消除这种风险的选项是不将生产细节存储在SVN中：

让管理员覆盖用于连接数据库的系统属性，或者
让容器管理数据库连接而不是c3p0，这样他们就可以自己管理这个配置。

你有什么建议吗？

Answer 1

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

例如，如果您的应用程序已部署到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获取连接，而您的应用无需提供用户名或密码。管理员在prod服务器上保护tomcat安装，因此在您的prod服务器上没有管理员权限的任何人都无法使用它。

Answer 2

在制作中，我倾向于根本不在属性文件上存储凭据。相反，我更喜欢应用程序服务器使用jndi提供凭据。

如果您使用的是Apache Tomcat，请参阅他们的jndi reference。

Answer 3

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

有些注意事项：

在可能的范围内，您可以拥有属性的默认值，这样如果找不到该属性，它将使用默认值（例如，使用“localhost”作为默认数据库连接URL）。
您仍然可以将源代码管理中的非生产环境的属性文件与代码一起保留。

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

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

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

3 个答案: