Help with Cloud VM

[seamus]

I'm moving my site from shared hosting to a CloudVM package and I'm having a problem setting things up so that my php includes will work.

I've been using the following include to call the header to my pages

<?php include ("header.htm"); ?>

but it wont work on the new server.

Can anyone tell me what I need to change in my Plesk Control Panel so that they'll start working?

[penders]

When you specify a relative path to the include, PHP uses the

include_path

to try and find the file. What is the

include_path

? Where is "header.htm" located in relation to your page?

echo get_include_path()

[seamus]

header.htm is in the httpdocs folder with my index.html

If you go to [46.22.134.63...] and view source you'll see how I'm trying to call the header which is at [46.22.134.63...]

This used to work on my shared hosting package but doesn't work now.

Where or what do I do with echo get_include_path()
Sorry if my question sounds a bit silly.

[penders]

It doesn't look like your PHP code is being executed at all as there is raw PHP code in the page source!

It looks like your index file is "index.html"(?), which obviously does not have a ".php" file extension. Most servers are only configured to process ".php" files for PHP. If this is the same file from your old server then you probably added a directive (AddType or AddHandler) in .htaccess to process ".html" files as PHP. However, the exact directive you would need on the new server might differ.

Alternatively rename the file with a ".php" file extension, although that might require more work, if you have a lot of files and they all link up and they are already indexed etc. etc.

[seamus]

Thanks Penders, you said enough to jog my memory. I had forgotten to upload my .htaccess

Thanks a mill

[ian_D]

<?php include ("header.htm"); ?>

That's a really unsafe way to do an include.

If there is no header.htm immediately relative to the code being processed, the server looks for another header.htm anywhere in the defined system variables. You could end up including something from /tmp for example. Enable full error messages and you'll see the paths searched when this happens.

I've even seen this exploited to include remote code.

It's best to use absolute path
<?php include ("/home/sitename/www/header.htm"); ?>

or absolute relative path.
<?php include ("./header.htm"); ?>

The "./" means "here" or current working directory.

A simpler way to get and use full path info:
$path = getCWD();
include ("$path/header.htm");

In this example $path returns "/home/sitename/www".

[penders]

That's a really unsafe way to do an include.

I think that maybe you're slightly overstating the security implications of a relative include. (?)

...the server looks for another header.htm anywhere in the defined system variables. You could end up including something from /tmp for example.

It searches for header.htm in PHP's

include_path

- no other "system variables". The

include_path

should never include the /tmp folder. If the system has been sufficiently compromised to modify the include_path then there's probably other things to worry about.

If there is no header.htm immediately relative to the code being processed, ...

Actually, it's the other way round. The

include_path

is searched first, before defaulting to the script's directory and the cwd. However, "." is often included as part of the include_path so the current directory ends up being searched early anyway.

I've even seen this exploited to include remote code.

I think that this perhaps involved some other kind of exploit? Or perhaps there was an inherent vulnerability with the version of PHP? PHP does not check absolute URLs in the include_path (even with allow_url_include set - which can only be set at the server level) when performing a relative include. They are simply ignored. Only when absolute URLs are specified directly in the include statement itself will PHP try to fetch the remote resource.

or absolute relative path.

A path relative to the current directory is better from a performance point of view (the include_path is not searched), however, it's not necessarily a whole lot more secure. "./" and getcwd() are both susceptible to changes in the cwd, which could occur if a script was compromised.