Building Production Release - DB Connection Credentials

Question

We have a build that can package war files for specific environments where all our property files are embedded in the archive (war file).

We are now about to build for production. My concern is the codebase will need to expose the production database password and although unlikely there is a risk where the production build profile could be run with a negative effect.

Options I thought of to negate this risk is to not store the production details in SVN and:

1. Have the administrators override system properties which are used to connect to the DB, or

2. Have the container manage the DB connection instead of c3p0, this way they can manage this configuration themselves.

Do you have any advice?

Answer 1

You should definitely not be putting the production DB username and password into your source control system. Your app should be getting its DB connection (eg a DataSource) using JNDI which is controlled/restricted by the admins on the production environment.

For example, if your app is deployed to Tomcat, you have the following in 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"/>

..and the connection is obtained from java:/comp/env/jdbc/myDB without your app ever having to provide a username or password. The tomcat installation is protected on the prod servers by the admins, so it is unavailable to anyone without admin access on your prod server.

Answer 2

In production I favor the approach to not store credentials on property files at all. Instead I prefer the application server to supply the credentials using jndi.

If you are using Apache Tomcat, see for instance their jndi reference.

Answer 3

I have tried both having properties in the archive and outside of the archive, and having them outside of the archive is much easier to manage this kind of problem.

Some things to note:

1. To the extent that is possible, you can have defaults for properties, so that if the property is not found it will use the default (for example, using "localhost" as the default database connection URL).
2. You can still keep property files for non-production environments in source control alongside the code.

Using these two policies, developers can be responsible for managing non-production property files, which also therefore serve as examples to the production admin. It also keeps most of the properties centralized in source control, giving some of the benefits of keeping things centralized, while still decoupling the properties enough.

EDIT: Note that JNDI is an option, but architecturally it is the same as storing property files outside - you still need to take care to version these not have them be loose in different environments.