JOB: LAMP Artisan

keith smith klsmith2020 at
Fri Feb 28 08:14:39 MST 2014

I'm curious about putting my PHP code outside of the webroot.  Lets say you do so.  How do you run your code?  Do you put an index in the docroot and then what?  Are you using a symlink?

It sounds like you think this is the only way and to do otherwise is wrong.  Every app I am familiar with is in the webroot someplace.

For example:


I' ve only known of one person who put some of his code outside of the webroot. 

I'm truly curious about your approach and you might be onto something.  However your approach is not mainstream - which does not invalidate it it is just not mainstream.

I would like to hear more.

In a previous response I stated that one needs to do two thinks to minimize the risk of being hacked.  We are talking PHP here,  I'm sure this approach will work for other interpreted web languages as well.  

First create your app with one entry point, second block direct access to all other files.

This approach secures your code.  The other thing is to sanitize your data.  The only way data can get in, when building your app this way, is via the URL and forms.  If you sanitize this data you should have a very secure web app. 

If you look at CodeIgniter that is what they do.  You enter the process though the index file.  All other files have a line at the top to verify the code is being accessed by CodeIgniter not directly.

One of the things we see with PHP is the use of library files that contain queries that can be accessed directly.  This approach leaves PHP vulnerable to being exploited.  I see this approach all the time.  The reason most of this code does not get exploited is no one knows enough to exploit it.  However using this approach in an open source project opens the door to someone exploiting the code.

I started out as an average PHP programmer and learned from available tutorials.  We have learned bad development techniques.  I inherited some old code that was based on an open source project and someone found it and exploited it.  I'm glad they did because it opened my eyes and was a great learning experience.  

Another thing that helped me understand all of this was evaluating PHP frameworks.  I spent a lot of time doing so.  I ended up spending a lot of time looking at CodeIgniter.  I actually got into the code.  Was a great learning experience that has shaped my views of how we should be developing our apps.

In my opinion it is the programmer that is the problem, not PHP.  Someone wrote that code can be seen if the server is configured incorrectly.  That is not PHP's issue, it is they sys admin's issue. 

And to take it further it is the PHP community that is the problem.  For far too long we have fostered bad development techniques.  Look at all the how-tos and PHP programming tutorials.  Lots of bad stuff out there.  

We need to start learning and fostering a different mindset.  We need to start building apps using OOP and Model-View- controller.  Apps that have one entry point and all other files cannot be accessed directly.  I would suggest a framework, or rolling your own.  I personally am in the process of rolling my own.  Interestingly I am finding that code built this way is easier to maintain as well.   

Keith Smith

On Friday, February 28, 2014 3:35 AM, Dan Egli <ddavidegli at> wrote:
On Fenruary 26, 2014, Michael Torrie wrote:

>> same misconfiguration can result in dumping Python, Perl, Ruby, etc...

> Actually, this is not really possible with Python, Ruby, or Java, since

> the code generating the page is never accessable to the web server.

Well, I never brought up Java. Java servlets are pre-compiled IIRC, so
that's completely different.

> It's outside the webroot. The only interface to it is the callable

> interface (tha API).

That's how it SHOULD be done, yea. And it's how PHP should be done too. But
I've seen examples here and there of perl and python scripts in the web
root. I've never seen ruby at work at all, so I can't anything good or bad
about it except what I've seen when I glanced at articles about programming
in it, and that has nothing to do with the topic at hand. Point being there
are always people who will go for the shortest, quickest approach. Those
are the people who give ANY language a bad name. I can take the time and
write a perl program that is careful, checks itself, and does it's job
well. Or I can write a perl script in a couple hours that grabs input and
works on it, regardless of if that input is actually correct. The latter
can make perl look like a bad language. Same with python. And the same with
PHP. I've only seen a few php routines that were stored in /var/www/html
(or other webroot). 98% of the PHP work I've seen, and all I've done
(except for quick things that I delete later) exist in their own /var/www/*
directory (or even outside of /var/www). Because they are outside the
webroot, requesting the page does not return it's code, but executes the
page and returns the output.

Let's just summarize this way. Are there bad PHP programs that are setup
with very poor security? Absolutely. Are there good PHP programs that are
written well and are as close to bug free as possible? You better believe
it. Can you make horrible security mistakes in Python, or Perl? Yes you
can! Is PHP worse than any other language? That's a very subjective
question. Some people will knee jerk yes. Some people will consider and say
yes. Some will consider and say maybe. Some will consider and say no. Some
will knee jerk and say no. I, myself, consider and say no. It's no worse
than any other language that's built on top of tons of 3rd party
contribution. If you think the PEAR archive has problems then I guess you
don't consider CPAN any better. I'm sure Python has a similiar repository

--- Dan

On Wed, Feb 26, 2014 at 8:29 PM, Michael Torrie <torriem at> wrote:

> On 02/26/2014 02:30 AM, Dan Egli wrote:
> >> Some configurations of PHP and/or Apache make it possible to view the
> >> source of a PHP file from over the web, including the aforementioned
> >> global configuration file.
> >
> > Well, that would be a problem, yes. But that's due to poor configuration
> in
> > the apache config file, not due to any problems in the PHP language. The
> > same misconfiguration can result in dumping Perl, Python, Ruby, etc....
> >
> Actually, this is not really possible with Python, Ruby, or Java, since
> the code generating the page is never accessible to the web server.
> It's outside the webroot. The only interface to it is the callable
> interface (the API).
> CGI is another story, of course, but normally CGI scripts also live in
> their own directory, outside the webroot.
> /*
> PLUG:, #utah on
> Unsubscribe:
> Don't fear the penguin.
> */

PLUG:, #utah on
Don't fear the penguin.

More information about the PLUG mailing list