1

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

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

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

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

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

你有什么建议吗？

4

3 回答 3

2

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

例如，如果您的应用程序部署到 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 安装，因此任何没有管理员访问权限的人都无法使用它。

于 2011-01-31T16:36:24.507 回答
0

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

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

于 2011-01-31T16:34:15.237 回答
0

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

需要注意的一些事项：

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

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

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

于 2011-01-31T16:34:47.467 回答