Re: [WSG] Proper extension and directory for server side includes
This is what made sense to me: save the included files as myfile.inc.php (so I know at first sight it is an include ), put all of them into an 'includes' directory inside the server root ( so it's easier to port the whole thing to another server ) and prevent Apache from serving anything from that directory with a .htaccess file containing: order allow, deny deny from all This effectively makes the content of the directory unreachable from any web client, while PHP doesn't care for .htaccess files. Even if PHP was to break down, the file content will not be sent to the client. It's more or less the same as putting it outside the server root, except the portability. djn b) simply use the extension of your server-side language (again, in the case of PHP, simply use .php) This way, in the worst case, somebody who tries to access an include file on its own will only see any output the include might generate. They won't see the source code, and won't see things like database connection details or any other business logic. Now, on the subject of directories: an additional safeguard to prevent people from accessing includes in their browser on their own is to have a directory for include files which is completely outside of the normal web root, meaning that it's not possible to actually get to them from the web. Only your server-side language - as it can access your server's real file system - can get to them when generating the page. begin:vcard fn:Dejan Kozina n:Kozina;Dejan org:Dejan Kozina Web Design Studio adr:;;Dolina 346;Dolina;TS;I-34018;Italy email;internet:[EMAIL PROTECTED] tel;work:+39 348 7355 225 tel;fax:+39 040 228 436 tel;home:+39 040 228 436 tel;cell:+39 348 7355 225 x-mozilla-html:TRUE url:http://www.kozina.com/ version:2.1 end:vcard
Re: [WSG] Proper extension and directory for server side includes
Thank you. Yes, it makes perfect sense. I'm using FutureQuest for hosting. I can move around the directory structure using their "Control Panel" (a web app), but I'm not sure that others can. I know I can restrict access to a directory with .htaccess. I believe the server uses Apache, probably 1.3. I know that I have access to change mode file permissions, but I'll have to read up on what that means; i.e., is the server considered a user, group, etc.? In any case, since my server handles php files, I'll just use .php as the extension on all include files. Again, thanks, -- Larry Mail may be sent to rapp at lmr dot com. Please use plain text only as html is filtered out as spam. On Wed, 10 Nov 2004 19:59:18 +, you wrote (with possible editing): >I've always advised my web authors to do one of two things: > >a) either set up your server to also parse .inc files (e.g., if you're >using PHP, set >your server so it handles .inc files the same way it would .php ones); or >b) simply use the extension of your server-side language (again, in the >case of PHP, >simply use .php) >This way, in the worst case, somebody who tries to access an include >file on its own will only see any output the include might generate. They >won't see >the source code, and won't see things like database connection details or any >other >business logic. > >Now, on the subject of directories: an additional safeguard to prevent >people from accessing includes in their browser on their own is to have a >directory >for include files which is completely outside of the normal web root, meaning >that >it's not possible to actually get to them from the web. Only your server-side >language - >as it can access your server's real file system - can get to them when >generating >the page. > >Hope this makes some kind of sense. If you *are* using PHP, have an >additional look >at http://www.php.net/manual/en/security.php > >Patrick H. Lauke >_ >re·dux (adj.): brought back; returned. used postpositively >[latin : re-, re- + dux, leader; see duke.] >www.splintered.co.uk | www.photographia.co.uk >http://redux.deviantart.com > >** >The discussion list for http://webstandardsgroup.org/ > > See http://webstandardsgroup.org/mail/guidelines.cfm > for some hints on posting to the list & getting help >** > ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Proper extension and directory for server side includes
Larry Rappaport wrote:
I have been told that it is improper to use .inc as an extension for
server side includes. Ex: menu.inc.
What is the proper extension to use for server side includes and into
which directory should they be placed?
It all comes down to how your server is set up. In the majority of cases,
servers are not set up to do anything special when encountering files with
a .inc extension. Although this does not impede execution when included
(e.g. in PHP, include('blah.inc') will still work), there is a danger
that if anybody
finds out the location of the includes, they can just open them in their
browser
and see them as clean text (as, by default, the web server will send any
files
with an extension it doesn't know how to handle as text/plain). Now, if
you have
include files that also contain information like database connection
details with
usernames and passwords, this would mean that anybody who (accidentally
or not)
finds your includes, they can simply read this type of sensitive
information.
I've always advised my web authors to do one of two things:
a) either set up your server to also parse .inc files (e.g., if you're
using PHP, set
your server so it handles .inc files the same way it would .php ones); or
b) simply use the extension of your server-side language (again, in the
case of PHP,
simply use .php)
This way, in the worst case, somebody who tries to access an include
file on its
own will only see any output the include might generate. They won't see
the source
code, and won't see things like database connection details or any other
business
logic.
Now, on the subject of directories: an additional safeguard to prevent
people from
accessing includes in their browser on their own is to have a directory
for include
files which is completely outside of the normal web root, meaning that
it's not possible
to actually get to them from the web. Only your server-side language -
as it can
access your server's real file system - can get to them when generating
the page.
Hope this makes some kind of sense. If you *are* using PHP, have an
additional look
at http://www.php.net/manual/en/security.php
Patrick H. Lauke
_
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
RE: [WSG] Proper extension and directory for server side includes
Hi, I use a method I picked from a tutorial I read somewhere a while ago. I give them the extension '.htmlf' where the f stands for fragment and I simply keep them in a folder called 'includes'. I don't think there is a proper convention, or at least I've never bothered to find one. :) Iain -- Iain Gardiner http://www.firelightning.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Larry Rappaport Sent: 10 November 2004 19:39 To: [EMAIL PROTECTED] Subject: [WSG] Proper extension and directory for server side includes I have been told that it is improper to use .inc as an extension for server side includes. Ex: menu.inc. What is the proper extension to use for server side includes and into which directory should they be placed? Thank you, -- Larry Mail may be sent to rapp at lmr dot com. Please use plain text only as html is filtered out as spam. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ** ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
