[RESOLVED] PHP 5.1.4 to 5.2.5 hosting issues

nrg_alpha

My hosting service provider was using PHP version 5.1.4. My site was working correctly on this version using require() functionality. Then I check my site yesterday only to find that there is an error with require..

The error involves: 'URL file-access is disabled in the server configuration'.
When I first signed up with the hosting company, I had a similar issue. But in that first instance, it was merely an issue of downloading my php.ini file and changing the second variable 'allow_url_fopen' to on (default was off) and uploading it back. So now as of yesterday, my page will not fully load. I double checked my php.ini file and this variable is still set to on (perfect.. this is what I was looking for).

I sent in the issue with the hosting service provider.. Basically, they replied back saying that my include path is this: include_path='.:/usr/local/php5/lib/php'..

But they turn around and tell me that I need to reference /usr/bin/php instead. I suppose this is done in the php.ini file? While I await their feedback (which can be up to 24 hours), I'm just curious if it's something I do on my end since they upgraded php. The paths of the site folders and directories seem to be correct and checks out.. so if I need to alter something in the php.ini file, what is it?

Cheers,

NRG

NogDog

I do not believe it is an include path issue, but is an allow_url_fopen issue as you suspected. It can only be changed at the system level, so if you have access to the php.ini file, you can change it (don't forget you then have to restart the webserver).

However, note that if you need to include/require a file, you normally want it to be a file on the local file system, so you should not need to access it via a URL. (Including/requiring a file by URL also can be very dangerous if the server from which it is being retrieved is not 100% reliable and secure.)

Weedpacket

But yeah, include_path is set in php.ini (the setting labelled "include_path"). But if the same php.ini is setting allow_url_fopen to be on, and it's off, then your php.ini is not being found. Where does phpinfo() say it's getting php.ini from?

nrg_alpha

Thanks for the response guys.

I totally forgot about phpinfo(); So I looked it up on my hosting company by making a very simple page that assigns $x to phpinfo() and echoed it.... I think I found the issue...

http://www.pbase.com/image/93871873/original.jpg

The 'allow_url_include' is set to off.. both for local and master... Guess I should point this out to my hosting service provider, eh? 🙂

By the way.. what's the difference between local and master in this case? Just curious..

In any case, thanks for the input guys... very much appreciated.

Cheers,

NRG

Weedpacket

Incidentally, phpinfo() does its own output; all it returns is whether it was successful or not (though offhand I don't see that happening very often).

The difference between Master and Local: Master is the configuration it had when it started up (from php.ini, the location of which is given in the first section), and Local is whatever settings all the various bits had at the time that phpinfo() was called (after things like ini_set and so on).

nrg_alpha

Thanks for the explanation, weedpacket.
I still await a report from my service provider on the matter.. but I convinced more than anything that the 'allow_url_include' must be set to on ("1") for my site to work.

Locally, I am using PHP 5.1.2 build 2600.. I did a phpinfo() on mine, and there is no such 'allow_url_include' variable.. so I am assuming that the include functionality must have been lumped into the 'allow_url_fopen' instead.. so it appears that in version 5.2.5 this has been split up and given their own distinct settings. And I suspect this is where the problem is creeping in.. it seems that tech support isn't aware of this new setup, and thus just left 'allow_url_fopen' on and left the default of 'allow_url_include' to its default off setting..

Hopefully, this will be resolved soon enough. It's frustrating to see a page load partially and break.

Cheers,

NRG

Weedpacket

nrg_alpha wrote:
I did a phpinfo() on mine, and there is no such 'allow_url_include' variable

Yes, according to http://www.php.net/manual/en/ini.php allow_url_include has been available since v5.2.0.

nrg_alpha

Thanks again, Weedpacket. It does prompt me to wonder though.. why would this variable in the configuration be set to off by default? I mean, good smart php design might rely on include(), include_once(), require() and require_once() to keep certain sections of websites separate for easy changes that propagate site wide.

Shouldn't this variable be on by default? Unless this poses as some form of risk of some sort?

Cheers,

NRG

laserlight

It does prompt me to wonder though.. why would this variable in the configuration be set to off by default? I mean, good smart php design might rely on include(), include_once(), require() and require_once() to keep certain sections of websites separate for easy changes that propagate site wide.

Shouldn't this variable be on by default? Unless this poses as some form of risk of some sort?

I do not think it is a security issue, but a good practice issue: typically if you include/require a file, it is because that file has PHP code, and you wish to access the variables, functions and classes in the included file. But a file included via URL only has client side output, without PHP code to be parsed (i.e., any PHP code was already parsed), and this may not be what is expected. One might as well use file_get_contents() or readfile() instead.

NogDog

As LL pointed out, the only reason you need to use include/require is if the file being included contains PHP code to be parsed and executed as if it were in the calling file at that point. If that is not the case, then you should use [man]readfile/man.

There is a security issue: when including from a URL, that URL could be to a site that is not directly under your control. Suppose the file on that site which you include gets changed to the following:

<?php
echo '<'.'?php
[a bunch of code here to read all the files on your site with a .php suffix and
send their contents via cURL to a hacker\'s site]
?'.'>';
?>

And if the file is on the same server as the caller, then there's not reason to include via URL: you should instead include via a relative or absolute file system path.

nrg_alpha

To LaserLight:

Thanks for the clarification. I wasn't aware that one should only use include() / require() to get separate files that contain php code in it. I was under the impression that you use that regardless.. I have double checked my .php files that are involved in the require() and they all do incorporate php code. But nice to know to use readfile() in non php code.

To NogDog

Yeah, I always use absolute paths.. there is no server confusion when I utilize include() or require(); I am always mindful to make sure the path cannot be ambiguous or confusing.

Cheers,

NRG

NogDog

Just to clarify, it's an issue of accessing a file via HTTP using a URL instead of via the local file system:

// dangerous, especially if you do not control the external site:
include 'http://www.external_site.com/script.php';
// if you just want the output from that site:
readfile('http://www.external_site.com/script.php');

// Unnecessary if local server and adds webserver processing:
include 'http://www.local_host.com/includes/script.php';
// Should be:
include $_SERVER['DOCUMENT_ROOT'].'/includes/script.php';

nrg_alpha

Very interesting, Nogdog.. I am using this format:

include 'http://www.local_host.com/includes/script.php';

And this method causes more overhead you say? (as compared to using $SERVER['DOCUMENT_ROOT']). Just out of curiosity, why is that? I figured if you stick to the explicit path, PHP does not have to calculate what $SERVER['DOCUMENT_ROOT'] actually is. Man, I have so much to learn..

Cheers,

NRG

bpat1434

$_SERVER['DOCUMENT_ROOT'] is already known to PHP. It should save some overhead by locally including since an HTTP request doesn't need to be sent out for the file 😉

NogDog

The "http:" sends it as a HTTP request to the web server, which then processes that request, determining what file(s) to open, whether or not to send them through the PHP parser first, etc. When you call it via the filesystem, you bypass all of that, and PHP can directly open the file in question via a basic OS file system call. ($_SERVER['DOCUMENT_ROOT'] is the absolute path to your site's root web directory, so it will resolve to something like "/home/users/loginname/publc_html" or "c:\apache\sitename\www", etc.)

Also, if you want to include a file with PHP code in it to be processed within your script (function/class definitions, variable/constant declarations, etc.), you generally must call it via the file system unless you give it a file suffix which the web server will process as plain text. Otherwise all you will get is the output of that script, not the actual PHP code.

Weedpacket

nrg_alpha wrote:
And this method causes more overhead you say?

As NogDog says, yes: a whole http request's worth of overhead.

There's a more fundamental issue, as well.

A common mistake, responsible for many HTTP implementations problems, is to think [a URI] equivalent to a filename within a computer system. This is wrong. URIs have, conceptually, nothing to do with a file system. One should remember that at all times when dealing with the World Wide Web.

http://www.w3.org/TR/chips/

nrg_alpha

Thanks for the responses bpat1434, Nogdog and weedpacket.
This is starting to make sense. The more I think about, the more it does make sense indeed.

Isn't $SERVER['DOCUMENT_ROOT'] basically a reserved super-global variable (much like $SERVER['PHP_SELF'] as an example)? If php auto assigns this, then I guess it would eliminate extra http header requests / responses.

In either case, I think I have been approaching this the wrong way. I think once my site is back to normal (i.e. my hosting service provider snaps out of it and finally sets the 'allow_url_include' variable to on), I am temped to restructure the paths to utilize $_SERVER['DOCUMENT_ROOT'], because it is already set after all.

Thanks again guys.. I can see why forums like this proves to be invaluable. Much appreciated!

Cheers,

NRG

laserlight

In either case, I think I have been approaching this the wrong way. I think once my site is back to normal (i.e. my hosting service provider snaps out of it and finally sets the 'allow_url_include' variable to on), I am temped to restructure the paths to utilize $SERVER['DOCUMENT_ROOT'], because it is already set after all.

You can use the $SERVER['DOCUMENT_ROOT'] with your includes even with allow_url_include set to off. That is probably better than getting your host to change the setting to on.

nrg_alpha

laserlight wrote:
You can use the $_SERVER['DOCUMENT_ROOT'] with your includes even with allow_url_include set to off. That is probably better than getting your host to change the setting to on.

LL, my current pathing structure is correct as is. My site was working perfectly prior to the PHP 5.2.5 upgrade. So I fail to understand why $_SERVER['DOCUMENT_ROOT'] would work while the current hardcoded (and correct) paths would not (unless I am missing something here that you can let me in on).

The 'allow_url_include' variable did not exist in 5.1.x settings.. this is a new setting. I have a strong suspicion that this needs to be set to 1 (on) to work.. I will try a sample subdirectory test later today to test whether using $_SERVER['DOCUMENT_ROOT'] makes any difference in this case. I would be surprised if it did, considering my current paths as is are correct, and the site is still not going past the first require() section. The current issue is the actual require() functionality that is currently blocked, not the pathing within the require();

Cheers,

NRG

laserlight

So I fail to understand why $_SERVER['DOCUMENT_ROOT'] would work while the current hardcoded (and correct) paths would not (unless I am missing something here that you can let me in on).

As you pointed out, you are currently using includes like this:

include 'http://www.local_host.com/includes/script.php';

See the protocol portion ([url]http://)?[/url] For such a path to be included, URL fopen wrappers must be enabled, and if applicable, allow_url_include must be set to on.

But what we are suggesting is that you do not include files using URL fopen wrappers, hence the use of relative paths or $_SERVER['DOCUMENT_ROOT'].