Cross domain include()?

[Ciaran]

Hi,
Can someone please outline the safest and easiest way to import some
code from another domain and run it?
Thanks,
Ciaran

[Michael Fesser]

..oO(Ciaran)

>Can someone please outline the safest and easiest way to import some
code from another domain and run it?

What's the reason for this? It will be insecure and slow.

Just make sure that the remote server doesn't parse the PHP code, but
delivers the code as-is.

Micha

[Ciaran]

On Jul 14, 10:34 pm, Michael Fesser <[e-mail]:

.oO(Ciaran)

Can someone please outline the safest and easiest way to import some
code from another domain and run it?

What's the reason for this? It will be insecure and slow.

Just make sure that the remote server doesn't parse the PHP code, but
delivers the code as-is.

Micha

Just thought it might be a good way to run a CMS system for my
customers from a central source on my own website that is easily
updatable, etc.

[Michael Fesser]

..oO(Ciaran)

>On Jul 14, 10:34 pm, Michael Fesser <[e-mail]:

>.oO(Ciaran)

>Can someone please outline the safest and easiest way to import some
code from another domain and run it?

What's the reason for this? It will be insecure and slow.

Just make sure that the remote server doesn't parse the PHP code, but
delivers the code as-is.

Micha

Just thought it might be a good way to run a CMS system for my
customers from a central source on my own website that is easily
updatable, etc.

Bad idea:

* For every single include file it requires an HTTP connection to the
remote server. Usually a CMS consists of dozens if not hundred includes.
This overhead will become measurable quite quickly. Even the include of
just a single file via HTTP will be much slower than direct disk access.

* All of your CMS source code would be readable to everyone who knows
the URLs unless you use SSL, which would make it even slower.

* Finally don't underestimate the caused network traffic on your own and
and the client servers. Especially on your side this may easily become
several hundred MB _per_day_ in the worst case.

The only sitation where this makes sense is if the various domains are
hosted on the same server under the same user account. Then of course
you can share a single CMS instance between the different sites.

Micha

[cwdjrxyz]

On Jul 14, 5:20*pm, Michael Fesser <[e-mail]:

.oO(Ciaran)

On Jul 14, 10:34 pm, Michael Fesser <[e-mail]:

.oO(Ciaran)

Can someone please outline the safest and easiest way to import some
code from another domain and run it?

What's the reason for this? It will be insecure and slow.

Just make sure that the remote server doesn't parse the PHP code, but
delivers the code as-is.

Micha

Just thought it might be a good way to run a CMS system for my
customers from a central source on my own website that is easily
updatable, etc.

Bad idea:

* For every single include file it requires an HTTP connection to the
remote server. Usually a CMS consists of dozens if not hundred includes.
This overhead will become measurable quite quickly. Even the include of
just a single file via HTTP will be much slower than direct disk access.

* All of your CMS source code would be readable to everyone who knows
the URLs unless you use SSL, which would make it even slower.

* Finally don't underestimate the caused network traffic on your own and
and the client servers. Especially on your side this may easily become
several hundred MB _per_day_ in the worst case.

The only sitation where this makes sense is if the various domains are
hosted on the same server under the same user account. Then of course
you can share a single CMS instance between the different sites.

I tend to agree with you, but there likely always are a few
exceptions. I have 2 domains, one with a subdomain, on the same
server, and sometimes share things without problems. This usually
involves only very large files, such as streaming video, that I do not
want to duplicate. Large data bases also come to mind. However there
is much to be said for putting everything needed for a page in the
same directory with it so you can nearly always use short relative
urls and do not have to worry that if you delete a file in some
directory it may have been needed by a file in some other directory.
This may mean duplication in various directories, but short of long
data and streaming video files etc, this is no problem for many these
days where you often have nearly unlimited disk storage provided. Disk
storage, in contrast to earlier days, is now nearly dirt cheap.

[Michael Fesser]

I wrote:

>The only sitation where this makes sense is if the various domains are
hosted on the same server under the same user account. Then of course

^^^^^^^^^^^^^^^^^^^^^^^^^

>you can share a single CMS instance between the different sites.

You wrote:

>I tend to agree with you, but there likely always are a few
exceptions. I have 2 domains, one with a subdomain, on the same

^^^^^^^^^^^

>server, and sometimes share things without problems. This usually

^^^^^^

Micha

[Ciaran]

On Jul 14, 11:20 pm, Michael Fesser <[e-mail]:

.oO(Ciaran)

On Jul 14, 10:34 pm, Michael Fesser <[e-mail]:

.oO(Ciaran)

Can someone please outline the safest and easiest way to import some
code from another domain and run it?

What's the reason for this? It will be insecure and slow.

Just make sure that the remote server doesn't parse the PHP code, but
delivers the code as-is.

Micha

Just thought it might be a good way to run a CMS system for my
customers from a central source on my own website that is easily
updatable, etc.

Bad idea:

* For every single include file it requires an HTTP connection to the
remote server. Usually a CMS consists of dozens if not hundred includes.
This overhead will become measurable quite quickly. Even the include of
just a single file via HTTP will be much slower than direct disk access.

* All of your CMS source code would be readable to everyone who knows
the URLs unless you use SSL, which would make it even slower.

* Finally don't underestimate the caused network traffic on your own and
and the client servers. Especially on your side this may easily become
several hundred MB _per_day_ in the worst case.

The only sitation where this makes sense is if the various domains are
hosted on the same server under the same user account. Then of course
you can share a single CMS instance between the different sites.

Micha

Hmm OK thanks for the input. It was just an idea anyways. it's a pity
it's not more feasible - it would be very handy if it was fast and
secure!
Cheers,
Ciarán

[C. (http://symcbean.blogspot.com/)]

On Jul 14, 10:34 pm, Michael Fesser <[e-mail]:

.oO(Ciaran)

Can someone please outline the safest and easiest way to import some
code from another domain and run it?

What's the reason for this? It will be insecure and slow.

Insecure?

No, but it does potentially open a new vector for attacks.

Slow?

Yes, but it might still be faster than an alternative approach.

For preference I would advise using rsync (preferably over ssh) to
replicate the code, but there are scenarios where this is a valid
approach (but if you understand the context where this is appropriate
then I'd expect that you wouldn't need to ask the original question).

In case the context is appropriate for the solution, it would probably
be more appropriate to use a caching copier to replicate the file
locally and include it from there.

C.

[burgermeister01]

On Jul 14, 4:19*pm, Ciaran <[e-mail]:

Hi,
Can someone please outline the safest and easiest way to import some
code from another domain and run it?
Thanks,
Ciaran

I'm not sure if I'm thinking about this on the same level as you, but
here is a thought:
If these PHP scripts you want to share among sites are all on the same
server, why not just change the include path in the php.ini file to
and upper-level directory that contains the common script files or
codebase? Check this out to get an idea of what I'm talking about (of
course this page speaks to an actualy PHP command, whereas I'm talking
about actually editing your config file in a permanant kind of way;
it's the same basic premise though):
http://us3.php.net/manual/en/functio...clude-path.php