> Of course the absolute safest way besides encryting
> your PHP is to just store your state secrets in files
> outside the web server's document tree.
>
> i.e.
> if your web server's document root is /var/www
>
> <?php
> require("/var/super-secret/super-functions.php");
> if ($theanswer == 42)
> {
> echo (findthequestion($theanwer));
> }
> ?>
>
> then even if you screw up the web server config
> and .php files are sent back unrendered all you
> expose is what's in the file above but not what was
> included/required statements.
>
> This is an excellent way to protect sensitive info
> like database passwords too.
Actually... On a shared server, this *STILL* leaves all those files
readable by "nobody", IE anybody else who can write PHP (or Perl, or JSP, or
shell script) on the server.
So while this is a good answer, and the "stock" answer, there *ARE* safer
alternatives, depending on what you can afford in time/resources.
#1. Compile PHP with the same settings *EXCEPT* not --with-apxs
(nor --with-apache) and add another, different AddType with another,
different mime-type and extension, along with an Alias and Action directive
to httpd.conf, along with suExec for Apache (http://apache.org) to wrap
around PHP. Whew. You can then create files ending in your new extension
which will run AS YOU. Yes, *YOU*, the *REAL* user will be running PHP and
have all the power and flexibility you have when you login.
THIS HAS INHERENT SEVERE RISK IF YOU DO IT WRONG!!!
You need to be damn sure that these directives *ONLY* apply in *YOUR*
<Directory > directive in httpd.conf. Otherwise, *ANY* other user of Apache
could make a new file with your nifty new extension and do *ANYTHING* to
your account.
You'll also want to test this setup under load as you need the PHP CGI to
run "fast enough"
#2. Buy the Zend encoder. http://www.zend.com This will make your PHP as
readable as word.exe Of course, anybody with enough time and intelligence
will be able to reverse-engineer *ANYTHING*... But they'd probably be able
to reverse-engineer your web-site just by looking at its behaviour faster
than dis-assembling Zend Encoded files.
#3. Convert the *REALLY* sensitive bits of your PHP into C code to be
compiled directly into PHP itself. Or maybe as PHP modules you can load in
with that new-fangled stuff Rasmus has been presenting lately...
http://conf.php.net
#4. If it's just database username/password, you can set vars in httpd.conf
or something... Never did it, never saw it done, it's just a rumor I heard.
You're on your own for this one, kid :-)
There are undoubtably *other* options beyond my ken, but there's a few.
NOTE: Don't over-estimate the value of the intellectual property of your
source code. There just isn't that much most of us are doing that is "all
that". Your primary concern should probably be that somebody find your
database passwords within your source, nor snag your whole site's PHP code
and totally rip you off.
--
WARNING [EMAIL PROTECTED] address is an endangered species -- Use
[EMAIL PROTECTED]
Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
