Geek Answers Handbook

Does PHP include file extensions?

For required / included files in PHP, is it better to use the .inc exts vs .inc.php vs .php extensions?

+4
source share
3 answers

Sometimes people use the .inc extension and then do some server configuration to keep .inc files from being accessed through a web browser. This may be good if you know the system administrator absolutely correctly, but there is a better way: any file that should not be used by web users should be stored outside your document root. Once these files are disconnected from the network, so to speak, you can use any extension you want. .php definitely a smart choice for syntax highlighting, general sanity, etc.

+15
source

Apache can sometimes (due to an error or a serious accident) serve .php files as text (HAPPENED to me several times for shared hosting) .... I think you can use any extension you want until you "t save your files in a shared folder.

Let's say your site is in / home / user / public _html /

create another folder / home / user / lib _php /

there are files:



(1) ... / lib_php / one.class.php with

 class one { //... }



(2) ... / lib_php / two.function.php with

 function two() { //... }

and you have the main index.php in / public_html 

 <?php include_once('../lib_php/one.class.php'); include_once('../lib_php/two.function.php');

$ x = a; $ b = two ($ x); $ c = new one; // etc ..

or

 <?php require_once('/home/user/lib_php/the.file.php');

Thus, you take all precautions that the files are not directly accessible, but can be used by your scripts ...

+1
source

My personal preferences are that all that is in the root of the document is a .php file to indicate it is directly executable by the web server, and all that the library is a .inc file stored in a parallel directory to indicate it is NOT directly executable file.

My standard configuration

/home/sites/example.com/html/ - anything here is "safe" to expose if PHP fails and provides raw code

/home/sites/example.com/inc/ - libraries, configuration files with passwords (for example, a database connection class with database credentials), etc. Everything that should not be disclosed, because there is no reason for this.

While you can certainly configure Apache to deny access to .inc files and keep them inside webroot, then you depend on Apache to keep you safe. If PHP can fail in Apache and expose your code, then .inc blocks can also fail and expose your internal instances.

Of course, if Apache coughs up blood across the floor, there is no reason why directory traversal protection cannot fail, and let someone do http://example.com/../inc/seekritpasswords.txt .

At some point, you just need to accept that if something is stored somewhere on the web server, there is a chance that the failure could allow access to the raw data and expose everything. How much time and effort you spend protecting it is up to you.

+1
source

More articles:


All Articles