allow_url_include

What objection do you have with simply copying the files over?

I can't see any advantage to doing the way you want to -
- it adds to page load time,
- it is a security issue
- If the remote server is down - this server also does not work

The only up side is that shared code is resident in one place but you can solve that with other solutions by having a central code repository (on GitHUB) for example and a script that runs on your various servers that pulls the latest build from there when there is a code base change.

Makes far more sense than trying to include code at run time.

The security issues are pretty serious with this approach, which is why it's turned off by default. It might help to understand those issues. Let's say you have a file called myscript.php on domainA.com, which is including a remote file like this:

<?php
include("http://domainB.com/header.inc.php");

You expect the header.inc.php file to have PHP code that connects to a database or something. In order for this to work, you first need domainB.com to NOT process the request for header.inc.php like it would normally do. Otherwise, domainB.com will be the one executing the code in header.inc.php instead of returning the code back to your script on domainA.com.

The simplest way to do this is to use a different extension that isn't automatically associated with PHP, so you rename your file to header.inc, so its URL is now:

http://domainB.com/header.inc

Now the domainB.com web server will just return the raw contents of header.inc instead of processing it as PHP. One configuration issue solved!

Now the security questions begin:

1. What happens when a hacker or malicious user accesses that file and can now see sensitive information like database connection information?

Well, I guess to help mitigate that you might use IP whitelisting or something so that only requests from domainA.com's outgoing IP can access the file. Well, that's more configuration to add to domainB.com.

2. What happens if a hacker changes the contents of that file and puts in code that will zip up all the source files and upload them to his / her own server?

Not too much you can do about that except HOPE that it never happens. If it does happen and someone hits your page on domainA.com, then not only will the hacker have probably gotten all the source code for domainB.com but now he'll get it for domainA.com, too, when the malicious code is included, even though the hacker never broke into domainA.com.

3. What happens if that file is permanently corrupted or deleted/lost somehow?

It might bring down domainB.com, but this now brings down domainA.com, too. Uh-oh. Hope you have another backup.

4. What happens if 3 years from now, some new person comes along and needs to make changes to domainB.com and so they make the code changes in domainB.com, which are harmless changes but they end up accidentally breaking something in domainA.com?

I guess now you have to roll back the changes or figure out a way to add conditions around the inclusion.

5. What happens if a hacker can't break into domainB.com, but he poisons the DNS cache on domainA.com, or performs a MITM attack on domainA.com so that the request for domainB.com is routed to his own IP/web server?

Give it a few minutes and he'll have full control over domainA.com, if not more.

6. What happens if domainB.com starts to slow down because of all the requests that are coming from every hit to domainA.com, which generate web requests to domainB.com?

Guess you have to buy a more expensive hosting plan.

7. What happens when domainA.com's performance starts to suffer because the included header takes 100 milliseconds to fetch, which adds 100 milliseconds of extra time to every request on domainA.com?

You can start to see where this is going...

Like Julian said, it's 10000% better to use local copies of files, and source control is a great way to handle some basic distribution/deployment so that you can make a change to a header file and use push/pulls to ensure the desired servers have the latest copy of the file.

Thanks Julian and gr8gonzo,

Very convincing explanations :) The reason I asked was to avoid to maintain the same template files on several domains, but I can see the riscs clearly now - so that's what I will keep on doing for now :)

But I am interested in knowing a little more about how I can pull the needed code from GitHub securely ??
I have a GitHub account but I have not used it so much yet, so I need to learn :)

Thanks Julian,

I will study that :)

Thanks

In the future, you can accept multiple comments as part of your answer to help mark which comments were helpful. It seems like the first 2 comments and the one you accepted were all relevant to your final answer.

Thanks gr8gonzo,

I will remember that.

Just to summarize the links that Julian provided (in case they ever break in the future), the general concept is to:

1. Set up a bare Git repository on the server where the web site is hosted,

2. Add a post-receive hook to it with these 2 lines:

#!/bin/sh
GIT_WORK_TREE=/path/to/webroot/of/mywebsite git checkout -f

Select allOpen in new window

3. Initialize a repository on your local development machine where you do the code changes, and add your initial files and commit them locally.

4. Use "git remote add" to tell your local repository where to find the remote repository (logging in via SSH):

git remote add live ssh://server1.example.com/home/user/mywebsite.git

Select allOpen in new window

5. Perform your initial push from the local repository to the remote repository:

git push live +master:refs/head/master

Select allOpen in new window

6. And from then on, after you do your updates and commits locally, just run "git push live" to send the commits to the remote server, where the post-receive hook will "checkout" the files into the web root.

The article also covers password-less SSH using keys, but that's an optional step that is covered in a variety of articles that can be found on Google (it's not strictly a Git concept - it's just SSH).

The StackOverflow article is more of a convenience item, when you want to push to multiple remote servers with one command. It all boils down to just using "git remote" to add another server:

git remote set-url --add --push live ssh://server2.example.com/home/user/mywebsite.git

Select allOpen in new window

That way "live" is linked to two different servers and when you do a git push live, you're pushing the data to both servers at the same time.

Thanks gr8gonzo,

I have to say that I don't understand how to make this work in my environment. Think I still am too much of a new-bee :) : Guess I'll stick to the copying model for now.

Source control is definitely something you want to master if you're going to be a developer. It's one of the most critical components you can know. If you're not familiar with Git, you can read my article on it here:

https://www.experts-exchange.com/articles/12235/Git-101.html

Thanks gr8gonzo

Nice article and nice analogies :) That makes sense.

But I still don't know how I am setting up the empty repository on my server. I work at hosted servers (Linux servers) at a hosting partner and I use one server for developing and some other servers to host my active domains. I do my coding on my local Mac.

As for now I have set up a repository at github.com and I have downloaded the local github app. It is this setup I need to get working :)

@Peter,

Can I suggest you open another question for this. Your original question has been answered and we are now branching off into a spin off question.