includes with ful URL in them

[the_pm]

Can someone give me a reason why this is a bad idea?

<?php include('http://www.example.com/somefile.php'); ?>

The reason I ask is because I'm putting together a site in which a mess of subdomains will need to pull common files out of the www directory. $document_root fails, because it take the include back into the subdomain. I could specify the entire path from the server root to the www directory, but if by chance this changes or they want to switch hosts, it's going to get really messy trying to change all of those paths.

The only downside I can foresee is if the site domain changes, and even then, you can maintain the domain and point your includes to it while maintaining the site itself under another domain name. So this isn't too big a drawback.

So, what am I missing? What makes this a bad idea, if there is a reason at all?

[Christopher Lee]

1. Because if somebody were to get control of that domain, they could have random code execute on your box. To try it out, input this single line of code into a file

<?php echo $_SERVER['HTTP_HOST']; ?>

and this is important, now save it as a text file (badcheck.txt), with nothing else in it. Now, on the calling box, enter:

include 'http://www.myremoteservergoeshere.com/badcheck.txt';

You can see that it will happily execute that code on the calling box, which could lead to bad things.

2. Not every box has allow_url_fopen set on his/her box. You'd have to run ini_get('allow_url_fopen') to see if it is enabled on the box you plan on using it on.

An alternative would be to have a config file with something like

define('ROOT_WS', 'path/to/includes/');


and then concatinate it to strings as needed. There are other ways to do it, but I just wanted to get this reply up for now.

[Christopher Lee]

Oh, and since include is a special language construct, the parentheses are not needed around the argument.

[the_pm]

Chris, the box I plan on running it on is my own :) I already know using the full URL will function properly, because I've tested it. But we don't have allow_url_fopen set on. I checked on this with our server admins a couple months ago while researching some options for an upcoming project, and we concluded there was too much risk in having this turned on. Are you saying that my include statements should not be working if this is turned off, and because they are working, it must be turned on??

Also, I like the direction you're going with the define statement that allows me to change the path for all include statements. Would I simply make sure this is within every page that uses an include? In that case...would I need to include it? :lol:

[Christopher Lee]

Well, I'm going off of what php.net tells me the behavior should be. Check your settings with

echo ini_get('allow_url_fopen');


if it prints a '1', well, it looks like it is set.

As far as the define, I usually have a 'top.php' or 'manifest.php' or some sort of file where I keep track of all of my includes. I'm not saying its the right solution, but its what I do. You could also create an ini file and put it in the path, but I've never done that before (mainly out of laziness and inertia) so I couldn't lend the voice of experience on that one. I'll see what I can find on that.

[Christopher Lee]

Yeah, you could add your include directory to your include_path using, it looks like, 3 or 4 different methods. Set it in your php.ini, use ini_set, set it via apache configurations files (http://us3.php.net/manual/en/configuration.changes.php). That might be your answer, but I'm dozing, so I'll check back tomorrow.

[the_pm]

It printed 1. That's not really good, is it :?

I'm looking in our php.ini file now. To disable this, do I set it = Off, or do I simply comment it out?

[Anoop]

Commenting out the line will set the value to default, which is 1. So set it Off.
As Christopher suggested, the solution for your problem is to add the path to
include directory to "include_path".
You can either edit your php.ini and add something like :
include_path = ".:pathtowww/includes" or you could set it in your php script using
ini_set("include_path", ":./include:../include");

[Christopher Lee]

Editing the php.ini file is something I've done VERY rarely, so I'd stick with Anoop's advice, rather than give any myself on that front. Make sure to have a backup ready.

[the_pm]

Thanks guys. Rather than edit the php.ini (other than to turn off allow_url_fopen), I used paths to the root. I have a handful of scripts residing in different levels, and this was giving me the most consistent response. I'm not going to worry too much about the server configuration for the time being. Resetting those paths will be quite easy if/when the time comes.

I just finished engineering a layout, and I engineered it to within an inch of its life using includes and case statements to insert those includes as necessary. I'm a GUI away from having a real content management system :)

[Christopher Lee]

Cool, glad you found a solution. Let us know how it goes :)