1

I am making a PHP script that people will have to purchase.

<?php
    session_start();
    $dbhost = "localhost";
    $dbname = "planeub9_airmanagemembership";
    $dbuser = "planeub9_malcolm";
    $dbpass = "mypassword";

    mysql_connect($dbhost, $dbuser, $dbpass) or die("MySQL Error: " . mysql_error());  
    mysql_select_db($dbname) or die("MySQL Error: " . mysql_error());  
?>

Is there any way that the db password can be hidden from plain view?

bjb568
  • 11,089
  • 11
  • 50
  • 71
Malcolm McSwain
  • 1,888
  • 2
  • 15
  • 17
  • You cannot let people connect to a database without letting them connect to the database. – SLaks Feb 05 '14 at 23:16
  • @SLaks That being said, surely there must be *some* alternative mechanism now than throwing plaintext passwords around in PHP files? – user2864740 Feb 05 '14 at 23:17
  • @user2864740: Not if you're distributing the source. – SLaks Feb 05 '14 at 23:18
  • @SLaks Granted, I only use ASP.NET, but it trivially supports web.config (which is "secured" and controlled *independently* of the source), and if I really wanted I could enable encrypted connection strings.. *nothing* like that for PHP? – user2864740 Feb 05 '14 at 23:19
  • impossible to make this 100% secure... – kasper Taeymans Feb 05 '14 at 23:19
  • 3
    If people are purchasing it, shouldn't they put in their own password and connect to their own database? Also, why are you using the super old, totally antiquated `mysql_query` method? – tadman Feb 05 '14 at 23:19
  • 5
    The general way is to supply a tarball containing an example configuration file, and to add an ignore command against your real configuration file into your version control system. When deploying their own app, the user must copy the example file to the correct name (e.g. "config.php.example" => "config.php") and fill in the blanks. – halfer Feb 05 '14 at 23:19
  • 1
    I hope you're not proposing to sell new code using the deprecated `mysql_*()` functions? You should migrate to `mysqli_*()` at the very least. –  Feb 05 '14 at 23:20
  • @user2864740: Not if you want to distribute the source to other people & let them run it. – SLaks Feb 05 '14 at 23:21
  • @halfer Could you possibly give me the link to a tutorial on that? I'm a bit confused... – Malcolm McSwain Feb 05 '14 at 23:24
  • @tadman I didn't know it was so ancient :). What other options are there? I'm still pretty new to PHP. – Malcolm McSwain Feb 05 '14 at 23:28
  • @halfer I'm using Git. – Malcolm McSwain Feb 05 '14 at 23:35
  • @malcolmmcswain http://bit.ly/LRtXQd – bjb568 Feb 06 '14 at 00:26

1 Answers1

3

I will start with assuming you would like to release a tarball or zipfile of your software project, rather than granting access to your whole Git repository. To do this, you can use something like git archive to create a release of your project.

Before you do this, you need to ensure that your configuration file is not committed to version control. If it is already, then copy it (for example copy "/config/base.php" to "/config/base.php.example") and reset all the settings to dummy values prior to committing it. Then remove the real config file from version control whilst leaving the physical file on disk.

To prevent this file coming up in your git status as uncommitted, add "/config/base.php" into your ".gitignore" file. This will help prevent you accidentally re-committing it too. Finally, add some instructions in your "README" to explain that "base.php" needs to be created as a copy of "base.php.example".


Now, if you wish to release the whole repo and you have already committed your configuration file, you have two options. Firstly, you can take the above advice about removing it from the repo now, and then change your database credentials. This will leave your private details in the repo, but they will be out-of-date and thus harmless.

Or, you can excise the configuration file from your repo entirely using git rebase. This causes problems if you have pushed the project to other contributors, who will have to pull a fresh copy and re-apply any pending changes. However, to remove something entirely from history, it is unavoidable (and if you let your collaborators know what is going on, quite easy to manage).

Community
  • 1
  • 1
halfer
  • 19,824
  • 17
  • 99
  • 186