NYCPHP Meetup

[Sexton, David]

So this looks like a wash... If you stop .inc files from being served raw
and exposing source code, you consequently cause them to execute as a "real"
.php file would. Placing .inc files in a locked down, parallel location
(without parsing them) sounds like the best solution to me (if you have that
option), but what are the downsides to executing included files? I guess it
depends on the code, but is there any significant performance degradation in
most instances? I'd make sure any third-party hosts are parsing .inc's
before placing them under webroot. That also makes the app less portable
since you can't be sure if you're moving to a server set up to parse inc's -
I mean it's portable, but you may be opening your app up to direct downloads
on a shared provider.

Another point in favor of .php extensions is that many editors have a PHP
template to make your code easier to read. I use Homesite and it does a
great job of highlighting the code if it's .php, but .inc is just plain old,
boring, hard to read text. Granted, you could config the editor to treat
.inc as .php, but why bother doing that if there is no other apparent
benefit to using .inc over .php?


-----Original Message-----
From: Russ Demarest [mailto:rsd at electronink.com]
Sent: Thursday, September 04, 2003 2:01 PM
To: NYPHP Talk
Subject: Re: [nycphp-talk] FUNDAMENTALS #1: Site Structure


.htaccess can be set to not serve .inc files. Doesn't require getting 
into apache config.

Russ

On Thursday, September 4, 2003, at 01:52  PM, Jim Hendricks wrote:

> I would agree to setting Apache to not serve .inc files except that I 
> want
> to maintain a consistent standard from one application to another.  I 
> don't
> have access to config Apache on many applications because the app runs 
> on a
> shared box.  Then there's when running under <gasp> IIS.  If I 
> standardize
> on the .inc extension protected via the web server then I need to have
> knowledge of how to do it in all the various environments I may work 
> in.
> Standardizing on putting incudes in a subdir of the app root & using 
> the
> .php extension to protect those include files from direct download 
> allows me
> to work in most any php environment, no need to have access to Apache, 
> no
> need to have access to ftp outside the webroot, no need for knowledge 
> of the
> web server either.
>
> This also allows me to work the same in PHP as I do in ASP.  Same 
> standard,
> different language.
>
> So I would also say that I fall into the 2nd category of I know the 
> risks
> but consider the convenience a worthwhile compromise.
>
> Knock on wood, but in 8 years of web app development ( mostly in ASP 
> and
> JSP ) I have yet to have an application hacked.  That may be mostly 
> luck,
> but I'ld like to think its partly due to the standards I've adopted.
>
> Jim
>
> ----- Original Message -----
> From: "Adam Fields" <fields at surgam.net>
> To: <shiflett at php.net>; "NYPHP Talk" <talk at lists.nyphp.org>
> Sent: Thursday, September 04, 2003 11:23 AM
> Subject: Re: [nycphp-talk] FUNDAMENTALS #1: Site Structure
>
>
>> On Thu, Sep 04, 2003 at 08:09:29AM -0700, Chris Shiflett wrote:
>>> I guess the answers could break down into three categories:
>>>
>>> 1. I place my includes under document root for convenience, and I'm 
>>> not
> aware
>>> of any problems that could cause.
>>> 2. I understand the risk in doing so, but I still place my includes
> under
>>> document root.
>>> 3. I place my includes outside of document root. It is a simple task,
> and it is
>>> at least more secure than doing otherwise.
>>
>> I typically name my includes with .inc extensions and set Apache to
>> not serve those files directly. This is both relatively convenient and
>> relatively secure.
>>
>> -- 
>> - Adam
>>
>> -----
>> Adam Fields, Managing Partner, fields at surgam.net
>> Surgam, Inc. is a technology consulting firm with strong background in
>> delivering scalable and robust enterprise web and IT applications.
>> http://www.adamfields.com
>> _______________________________________________
>> talk mailing list
>> talk at lists.nyphp.org
>> http://lists.nyphp.org/mailman/listinfo/talk
>>
>>
>
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
>

_______________________________________________
talk mailing list
talk at lists.nyphp.org
http://lists.nyphp.org/mailman/listinfo/talk


Please do not transmit orders or instructions regarding a UBS account by
email. The information provided in this email or any attachments is not an
official transaction confirmation or account statement. For your protection,
do not include account numbers, Social Security numbers, credit card
numbers, passwords or other non-public information in your email. Because
the information contained in this message may be privileged, confidential,
proprietary or otherwise protected from disclosure, please notify us
immediately by replying to this message and deleting it from your computer
if you have received this communication in error.  Thank you.

UBS Financial Services Inc.
UBS International Inc.