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?
1
Best practices suggest the following:
- 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 toconfig.phpand fill in the correct credentials. - 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.)
- 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.
- 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.
7
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.