JOB: LAMP Artisan

Richard Esplin richard-lists at
Fri Feb 28 09:32:32 MST 2014

Your argument is a perfect illustration of why PHP is the problem.

Modern web development frameworks do not allow code to be executed from the 

Modern web development frameworks make it easier to use sanitized inputs than 
raw inputs.

As you demonstrate, PHP does not have any popular web frameworks that have 
learned both of these basic lessons. And these are just two of the many bad 
practices that PHP encourages.

I use a web framework because I want to learn from a community that knows more 
about web development than I do. Otherwise I would write my own.


On Friday, February 28, 2014 07:14:39 keith smith wrote:
> 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:
> WordPress
> Joomla
> Drupal
> CodeIgniter
> laravel
> symfony
> cakephp
> ETC.
> 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

More information about the PLUG mailing list