.PHP vs .INC extension

[newb]

what's the difference of using it with the <?php include() ?> command? advantages/disadvantages? the only one i know of is with .inc file you can see the raw info if u put it in the browser and .php file you cant.

[maexus]

[!--quoteo(post=382640:date=Jun 11 2006, 03:35 PM:name=newb)--][div class=\'quotetop\']QUOTE(newb @ Jun 11 2006, 03:35 PM) [snapback]382640[/snapback][/div][div class=\'quotemain\'][!--quotec--]
what's the difference of using it with the <?php include() ?> command? advantages/disadvantages? the only one i know of is with .inc file you can see the raw info if u put it in the browser and .php file you cant.
[/quote]

*.inc.php >_>

[newb]

what?

[redbullmarky]

[!--quoteo(post=382654:date=Jun 11 2006, 10:13 PM:name=newb)--][div class=\'quotetop\']QUOTE(newb @ Jun 11 2006, 10:13 PM) [snapback]382654[/snapback][/div][div class=\'quotemain\'][!--quotec--]
what?
[/quote]

if your server is set up to parse .php files, and not .inc, then not only will you be able to view inc in its raw form, but no PHP within it will actually be parsed when included by an actual php file.
the only reason i can think of to do this would be to make it easier for you to determine between include files and actual php files, right?
in which case - either throw all your includes into an 'includes' directory on your server, or change the extension to .inc.php - so at first glance you can see it as an include file, but it will a) not be visible if someone types its path in, and b) any php within it will be parsed.

if you insist on using .inc, then unless you are keeping your .inc files in a directory outside your web tree, then really, its not worth it for all the security problems you will have.

Cheers
Mark

[newb]

ah ok

[poirot]

"Not parsed by PHP" means it will be output in raw form to the browser, allowing users to see it's code. Something like this:

[a href=\"http://www.stanford.edu/group/resed/row/synergy/includes/database.inc\" target=\"_blank\"]http://www.stanford.edu/group/resed/row/sy...es/database.inc[/a]

[newb]

is that good or bad

[poirot]

[!--quoteo(post=382736:date=Jun 11 2006, 09:30 PM:name=newb)--][div class=\'quotetop\']QUOTE(newb @ Jun 11 2006, 09:30 PM) [snapback]382736[/snapback][/div][div class=\'quotemain\'][!--quotec--]
is that good or bad
[/quote]
Bad, because people could no passwords, db names, possible vulnerabilities and other sensitive data.
Simply save them as .inc.php or .php and you will have less security risks.

include() in PHP is simply copy and paste, there is no difference if you use one extension or another for include().

[mainewoods]

The best page I ever found dealing with the include security issue is this:

[a href=\"http://www.phpbuilder.com/annotate/message.php3?id=1018208\" target=\"_blank\"]http://www.phpbuilder.com/annotate/message.php3?id=1018208[/a]

-All the different replies to that post mention about every different tactic you can take to the include security issue.

I put this script at the top of every include file:

[code]<?php

//**protection to keep includes from being called directly**
//determines whether it's file path and the parent path are the same
$abs_dir = $_SERVER['DIR'];
$inc_path = __FILE__;
$inc_relpath = '/' . str_replace($abs_dir, '', $inc_path);
$parent_path = $_SERVER['SCRIPT_URL'];
If ($inc_relpath == $parent_path) {
    exit; //show nothing!
    //could change to **forbidden** message later
}
//extra protection, I define this variable in the parent page
if (!isset($inc8897))
    exit;
//**end protection***

?>[/code]

-In order for that script to work on your web host, the $_SERVER variables I used have to be implemented on your web host. If they aren't use print_r($_SERVER) to find ones that are usable.