I have an open source project for mydomain.com which requires connections to a database (...as is tradition). What is the standard practice for allowing others to work on the site, without giving them full access to the database's credentials?

For example: If I have a connect.php page that connects to the database. I don't want someone to be able to read that file, or simply write <?php include("http://mydomain.com/connect.php") because then they will have full access to the database. If I put the file in my .gitignore file, sure the file won't be in the repo, but it'll still be visible in the source code.

Do I just make a read-only user and give them access to that, and then put the full read-write connection file and follow the guidelines of this answer?: Making sure database connection information is secured

What is standard practice here? or what can I research to learn more about this?

  • Have a separate file for external use and limit that users permissions in the database Dec 29, 2012 at 20:03

2 Answers 2


Best practices suggest the following:

  1. Do not commit database credentials or any other sensitive data to source control. Ever. Put those in a file (say, config.php) that is explicitly excluded from source control (through .gitignore / .hgignore / ...), and provide a placeholder file (say, config.dist.php) instead that contains only dummy credentials; then in your installation guide, tell people to copy this file over to config.php and fill in the correct credentials.
  2. Do not give anyone access to the production server. The database is the least of your concerns: if you allow people to upload arbitrary PHP, you might as well give them shell access, and preventing a skilled hacker from escalating to root from there borders on impossible. Instead, have people run their own private installs of the application. Provide an example apache configuration, php.ini, and some scripts to set up a test database (structure and data). You should have such an install kit anyway, if only for your own peace of mind. (What if your production server crashes beyond repair? Having an install kit that is proven to work means you can reinstall at any time, instead of having to come up with an emergency solution when the room is already on fire.)
  3. Review every single line of code that goes onto the production server, or even into the main line of development. If you are using a distributes source control system, have people work on their own clones of the main repository, and send you pull requests for any feature they want included in the main line. If you're still on centralized source control, give each contributor their own branch, and mandate that only you are to merge into trunk. Review every merge before you make it final.
  4. Test each version before deploying it. This should go without saying, but reality suggests otherwise. Also, make sure to use release tags; it's the easiest way to make sure no extra commits sneak in between testing and deployment (i.e., you want to make sure the version you're deploying is the exact version you have tested).

For a bit of a reference frame, consider yourself wearing two hats - the code maintainer hat, and the primary user hat. As code maintainer, you guard source control and anything that goes into it; as the primary user, you install the product on a server and open it to the public. Structure the whole project in a way that would allow you to pass one of those hats to someone else at any time without impacting your work under the other. At some point, you may want to share the burden of these duties, and when that happens, it will come handy if you have to trust people with either the main repo or the production server, but not both.

  • @tdammers Minor grammatical correction: You said "that is explicitly included" I think you meant "that is explicitly excluded". For 1), I like to do something a little extra (I don't know if this is possible for php). I make the path to the credential file configurable and set it to a path outside of the project. That way if I remove the source directory for some reason I don't have to recreate that file. This is convenient and less error prone, especially when you deploy to production. You don't have to worry about accidentally removing that file. Dec 30, 2012 at 1:32
  • @DanielKaplan: error fixed. Not grammar-related, but still wrong.
    – tdammers
    Dec 30, 2012 at 15:07
  • @DanielKaplan: Why don't you just keep a copy of the configuration file itself somewhere outside of the project root?
    – tdammers
    Dec 30, 2012 at 15:08
  • @tdammers That's what I'm saying. I guess I communicated it poorly. Dec 30, 2012 at 20:54
  • @tdammers maybe I misunderstood your question. Do you mean "why not keep a copy outside the project root and copy it inside the project root every time you delete the file?" Dec 30, 2012 at 21:06

Why would other developers want to work on production server? They should be working on either their own machines or shared non-production machine where they can do anything.

Also, all related configuration should be in configuration files. No such configuration should be in source code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.