Forum Moderators: phranque

Message Too Old, No Replies

At a complete loss as to why my server is requesting files

         

JS_Harris

6:29 am on Feb 11, 2016 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



My site has an area that, via php, calls a template file to serve as layout for the content in one section of my site. It's not much different than any site which calls a template file, except this template is not the main template, it only handles the content in one area. No iframes, all php, nothing fancy.

The code requests the file like it does ANY other file, and it works well, but the server logs tell a different story. Have you ever come across this?

- Visitor loads a page
- ip address of that visitor is stored along with the url requested
- ip address of the domain ip is stored along with the template file
- ip adress of that visitor is stored along with the url of everything else(image/css etc).

For the life of me I can't seem to figure out why this template file always displays in log files as having been requested by the domain ip instead of by the visitor ip, in fact I don't know why it appears at all, template file names usually don't. Is there a common issue that might cause this?

Problem it's causing:
- If I block requests with no referrer or user agent ONLY this section results in a 403 error, with the error file appearing right on the page in that area, when the visitor provides both. The server passes neither in delivering the file to the visitor on this page so always returns the 403 error document there.

whitespace

6:40 pm on Feb 21, 2016 (gmt 0)

10+ Year Member Top Contributors Of The Month



But, but, splutter-- But that's exactly what I would expect to see.


Just what I was about to say.

No, the redirect the host uses isn't behaving like a normal redirect.


But you did state earlier...

- The host creates a catchall redirect from subdomains to a folder of the subdomain at the server level(not in htaccess, can't be overridden)


If an external redirect isn't actually happening then there would seem to be nothing that needs to be overridden. (?) Although if there isn't actually an external redirect then it must be possible to override it?

if my addon site, which resides in a folder under the primary domain, makes a call to include a file the pathing is wrong. Accessing it with "/includedfile.php" or "./includedfile.php" works but if INCLUDEDFILE.PHP has code on it requiring a further include of something like a template file then things get screwy, the path must go all the way back up the chain and a local call does not work for includedfile.php, hence the 500 error message where the template are would have been on the original page.


"/includedfile.php" - This is relative to the filesystem root, so is unlikely to work. (I guess you mean without the leading slash?)

Using relative paths (particularly when you are including files inside another include) has potential to be a problem. What is it relative to? It's not necessarily the current working directory. When you use a relative path, the include_path is searched first. And when you have a relative include inside an include, it is relative to the included file, not necessarily the script that included the original file, unless the include_path overrides this and contains the current working directory (dot). Using an absolute filesystem path ("all the way back up the chain") is the common/safe way to handle includes as it removes any ambiguity, for example:


include($_SERVER['DOCUMENT_ROOT'].'/templates/mytemplate.inc.php');


Or, modify the include_path in your "loader/config script" to prefix the absolute filesystem path of your templates folder to the include_path. Then you can literally write include('mytemplate.inc.php') from anywhere. See this other WebmasterWorld thread: Controling include path using config.php [webmasterworld.com]

...hence the 500 error message where the template are would have been on the original page.


An "Apache" 500 error message?! This isn't PHP.

whitespace

9:12 pm on Feb 21, 2016 (gmt 0)

10+ Year Member Top Contributors Of The Month



include($_SERVER['DOCUMENT_ROOT'].'/templates/mytemplate.inc.php');


Just to add (briefly touched on earlier)... this (or any reference to DOCUMENT_ROOT) would be a problem if there was an external redirect from "addon.maindomain.com" to "maindomain.com/addon", since the value of DOCUMENT_ROOT changes.

When "addon.com" (or "addon.maindomain.com") is requested, the DOCUMENT_ROOT is of the form "/path/to/maindomain/addon", but when "maindomain.com/addon" is requested then the DOCUMENT_ROOT is obviously "/path/to/maindomain". (Default cPanel setup on a shared server with addon domains.)

JS_Harris

10:52 pm on Feb 21, 2016 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I'm having a really hard time explaining this :)

primary.com is the primary, it's root is / on the server (or public_html/ if you wish)
example.com is the addon and it resides in /addon/ (or public_html/addon/)

If I request any content on the primary domain it comes from /
If I request any content on the addon domain it comes from /addon/
** If I request content on the addon domain that makes a request from that domain(ie:include) it is loading that content but the include does not work at all from /addon/, period. Instead I can make it work from addon.primary.com or by going all the way up to the server level (www/site/public_html) but NOT from anywhere inside /addon/

So the pathing is as I would expect when I call a file but if that file calls one of its own... no dice. If I call /index.php and it calls /sample.php then index.php works and sample.php does not even though they are sitting right next to each other in the structure. The host has the include pathing up the wrong chain, it refuses to find it where I put it. Yes, that sounds like I am making a mistake but I have gone over this hundreds of times and tested on more than one host, only this one is doing this. It has something to do with how they handle addons behind the scenes, it's nothing I can fix.
This 33 message thread spans 2 pages: 33