NYCPHP Meetup

[Daniel J Cain Jr.]

On Thu, 2003-09-04 at 10:09, Chris Shiflett wrote:

<snip />

> 3. I place my includes outside of document root. It is a simple task, and it is
> at least more secure than doing otherwise.

It's been a long day, so please forgive me if it is too incoherent.

I prefer number 3, supporting files held outside the web directory.  If
this option is not available, and the supporting files are IN the web
directory I don't allow them to be accessed via a web browser.

This snippet of the logic I put in the beginning of each file I want
protected:

if($_SERVER['PHP_SELF'] == basename(__FILE__)) {
    header('Location: http://whereverIwanttoSendTheBadGuy.com');
    exit();
}

This will allow it to be included but will not allow it to be accessed
by a browser.  You could use whatever code you wanted if it was accessed
directly vs. inclusion from a legit script (verbose logging, take away
their birthday, etc.).

I also don't believe in the .inc, .class extensions for supporting
files.  I don't recall the bias origin but it was an article I read four
years ago that convinced me.  One plus is that everything is .php so one
less dependency on specific configuration options(config file "cleaned
up" by an overzealous admin at 3AM).

I try to keep things portable and under one directory on systems I can
have access to a dir outside a web directory.  Which works well with
multiple developers using CVS(once you get used to using CVS that is ;)
) to have a production site and multiple development sites keep
completely isolated code bases.  So along the lines of:

Production
==========
/usr/local/www/projectname   <-- Main directory of this project
/usr/local/www/projectname/htdocs   <-- web directory
/usr/local/www/projectname/classes   <-- class definitions dir
/usr/local/www/projectname/etc        <-- config files, etc.
/usr/local/www/projectname/libs       <-- function definitions dir

Development Area One
====================
/usr/home/dev1/projectname   <-- Main directory of this project
/usr/home/dev1/projectname/htdocs   <-- web directory
/usr/home/dev1/projectname/classes   <-- class definitions dir
/usr/home/dev1/projectname/etc        <-- config files, etc.
/usr/home/dev1/projectname/libs       <-- function definitions dir

An auto-prepend file modifies the include path so the site code uses
require_once('libs/housekeeping.php').  It also sets up an
ini_set('unserialize_callback_func','require_class') that handles
pulling in object definitions if the session contains an unknown object
in the require_class() user function.  Which grants the site code the
ability to require_class('user') that pulls in the "user" class
definition like a require_once would (by first seeing if the
class_exists() else require_once() the object definition file).

Almost all of my projects have been created on servers that I had root
access on, or known the admin of the box.  So I definitely do get into
some of the apache/httpd.conf stuff to tweak PHP settings and virtual
hosts.