Getting complete URL after a redirect

I am developing a CMS for an eCommerce site. Given how critical the
core eCommerce site is it has been decided in the interests of
security for the CMS to be hosted on a different server than the core
site and proxy requests on the core site for CMS content onto the CMS
server. The idea is that should the CMS fall victim to vandals or
hackers then the eCommerce site will remain unaffected and can
continue business, and no sensitive user information can be exposed.

One major requirement is for the redirection to be invisible to the
user, ie that if they visit www.foo.com/path/document.html they will
actually be served content from www.bar.com/ but the URL in their
browser window will still read www.foo.com/path/document.html

My idea on the CMS server side is to use a PHP errordocument. When a
request for content comes in the errordocument script runs, analyses
the URL that the user has been trying to access, and if it finds a
document in the database that has the correct URL, serve it.

I thought I could use $_SERVER ['REQUEST_URI''] to get what I need,
but I've since discovered that I can't because it only contains the
path portion of the URL. As the CMS may at some stage have to support
more than 1 eCommerce site I also need to know what the site name I am
being referred from is, ie what the user is seeing in his address
bar. Content in the database is organized in a hierarchy site > dir1
> dir2 ... dirN > document, so I need to know the referring site in
order to start my search down the tree for the right file to serve.

Can anyone help with this?

> One major requirement is for the redirection to be invisible to the
> user, ie that if they visit www.foo.com/path/document.html they will
> actually be served content from www.bar.com/ but the URL in their
> browser window will still read www.foo.com/path/document.html

I would not do that. Silly remark maybe, but instead of www.bar.com, I
would use something like cms.foo.com. What you are suggesting really
smells like an attack, even if it isn't.

> Can anyone help with this?

I would tell this story to your system administrators. They might be
able to configure a "load-balance-like" situation in such a way that
www.foo.com/ is handled by a different server than www.foo.com/cms/

If the redirection really has to be invisible, you should configure such
a situation on your own network or server.

Good luck,
--
Willem Bogaerts

Application smith
Kratz B.V.
http://www.kratz.nl/

On Dec 12, 10:15 am, Willem Bogaerts
<w.bogae...@kratz.maardanzonderditstuk.nl> wrote:
> > One major requirement is for the redirection to be invisible to the
> > user, ie that if they visitwww.foo.com/path/document.htmlthey will
> > actually be served content fromwww.bar.com/but the URL in their
> > browser window will still readwww.foo.com/path/document.html
>
> I would not do that. Silly remark maybe, but instead ofwww.bar.com, I
> would use something like cms.foo.com. What you are suggesting really
> smells like an attack, even if it isn't.

The thing is that the core server doesn't run PHP and the bosses don't
want PHP on that server on the grounds that it adds a potential avenue
for attack. It would also mean that the CMS would have to be
installed for every site it was planned to be used with, and that all
the sales staff would need logins for each instance of the CMS.
They're not exactly the sharpest tools in the shed when it comes to
technical stuff.

> > Can anyone help with this?
>
> I would tell this story to your system administrators. They might be
> able to configure a "load-balance-like" situation in such a way thatwww.foo.com/is handled by a different server thanwww.foo.com/cms/
>
> If the redirection really has to be invisible, you should configure such
> a situation on your own network or server.

That would be nice but unfortunately I'm working in a rather large,
beaurocratic organization where getting other departments to do things
for you can be difficult ant take up a lot of time. Setting up a
proxypass on the main server to the CMS server is just a whole lot
less hassle than getting IS to do things like setting up new
subdomains and servers.

Gordon wrote:
> On Dec 12, 10:15 am, Willem Bogaerts
> <w.bogae...@kratz.maardanzonderditstuk.nl> wrote:
>>> One major requirement is for the redirection to be invisible to the
>>> user, ie that if they visitwww.foo.com/path/document.htmlthey will
>>> actually be served content fromwww.bar.com/but the URL in their
>>> browser window will still readwww.foo.com/path/document.html
>> I would not do that. Silly remark maybe, but instead ofwww.bar.com, I
>> would use something like cms.foo.com. What you are suggesting really
>> smells like an attack, even if it isn't.
>
> The thing is that the core server doesn't run PHP and the bosses don't
> want PHP on that server on the grounds that it adds a potential avenue
> for attack.

So what are they using for their OS Commerce? ASP or .NET? PHP is used
on millions of sites world wide. If it's installed and configured
properly, any security problems are going to be from scripts. But
that's typically the weakest point in any language.

> It would also mean that the CMS would have to be
> installed for every site it was planned to be used with, and that all
> the sales staff would need logins for each instance of the CMS.

Sure, it would need to be installed. Big deal. Package everything -
Apache, PHP, your CMS, etc. together, write an InstallShield script for
it and send out the CD.

And even if it's on another server, they will still need to log in.

> They're not exactly the sharpest tools in the shed when it comes to
> technical stuff.
>

It only takes one competent person to do it. And it could be installed
and maintained remotely.

>>> Can anyone help with this?
>> I would tell this story to your system administrators. They might be
>> able to configure a "load-balance-like" situation in such a way thatwww.foo.com/is handled by a different server thanwww.foo.com/cms/
>>
>> If the redirection really has to be invisible, you should configure such
>> a situation on your own network or server.
>
> That would be nice but unfortunately I'm working in a rather large,
> beaurocratic organization where getting other departments to do things
> for you can be difficult ant take up a lot of time. Setting up a
> proxypass on the main server to the CMS server is just a whole lot
> less hassle than getting IS to do things like setting up new
> subdomains and servers.
>

Which still doesn't make your solution the correct one. Nor does it
make the requirements placed on you reasonable.

BTW - that's why I got into consulting - I got tired of this crap. Now
if they try to give me unreasonable expectations I can walk away. And
it's interesting how quickly some of those expectations change when they
see you are willing to do so.

But it's not so easy when you're an employee.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Dec 12, 1:54 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Gordon wrote:
> > On Dec 12, 10:15 am, Willem Bogaerts
> > <w.bogae...@kratz.maardanzonderditstuk.nl> wrote:
> >>> One major requirement is for the redirection to be invisible to the
> >>> user, ie that if they visitwww.foo.com/path/document.htmltheywill
> >>> actually be served content fromwww.bar.com/butthe URL in their
> >>> browser window will still readwww.foo.com/path/document.html
> >> I would not do that. Silly remark maybe, but instead ofwww.bar.com, I
> >> would use something like cms.foo.com. What you are suggesting really
> >> smells like an attack, even if it isn't.
>
> > The thing is that the core server doesn't run PHP and the bosses don't
> > want PHP on that server on the grounds that it adds a potential avenue
> > for attack.
>
> So what are they using for their OS Commerce? ASP or .NET? PHP is used
> on millions of sites world wide. If it's installed and configured
> properly, any security problems are going to be from scripts. But
> that's typically the weakest point in any language.

It's using a system based on a server side Java engine. I can't talk
a great deal about it because I honestly don't know a great deal about
it. It's maintained by a group of developers contracted to the
company. They want to keep the server locked down as tight as humanly
possible, so nothing goes on the servers other than the java eCommerce
engine, and the pages we design for it that are run through a template
engine server side (think Smarty).

> > It would also mean that the CMS would have to be
> > installed for every site it was planned to be used with, and that all
> > the sales staff would need logins for each instance of the CMS.
>
> Sure, it would need to be installed. Big deal. Package everything -
> Apache, PHP, your CMS, etc. together, write an InstallShield script for
> it and send out the CD.

I'm pretty sure the eCommerce boxes don't run Windows, and we're not
allowed to install things on them. It's a rather big business, we
can't afford to down a server because of faulty software or a security
breach, and the fewer scripting engines and other software the server
is running the less chance of that. Like I said, one requirement is
the potential ownage of the box running the CMS will not affect the
core eCommerce site. In addition to lost business there is also Data
Protection Act compliance to take into account. The main eCommerce
machines hold sensitive information about our customers (names,
addresses, credit card data if they agree to allowing us to store it,
purchase history, etc). If that information was exposed the
ramifications would be enormous.

We are most definitely not running osCommerce, and no remotely serious
eCommerce business should either.

> And even if it's on another server, they will still need to log in.
>
> > They're not exactly the sharpest tools in the shed when it comes to
> > technical stuff.
>
> It only takes one competent person to do it. And it could be installed
> and maintained remotely.

And it only takes 100 incompetent ones emailing our department every
day with inane questions to kill our department's productivity. :)

> >>> Can anyone help with this?
> >> I would tell this story to your system administrators. They might be
> >> able to configure a "load-balance-like" situation in such a way thatwww.foo.com/ishandled by a different server thanwww.foo.com/cms/
>
> >> If the redirection really has to be invisible, you should configure such
> >> a situation on your own network or server.
>
> > That would be nice but unfortunately I'm working in a rather large,
> > beaurocratic organization where getting other departments to do things
> > for you can be difficult ant take up a lot of time. Setting up a
> > proxypass on the main server to the CMS server is just a whole lot
> > less hassle than getting IS to do things like setting up new
> > subdomains and servers.
>
> Which still doesn't make your solution the correct one. Nor does it
> make the requirements placed on you reasonable.

Maybe it's not strictly speaking correct or elegant, but it's also
what I have to work with and that's that. No amount of complaining is
going to change how the organization works.

> BTW - that's why I got into consulting - I got tired of this crap. Now
> if they try to give me unreasonable expectations I can walk away. And
> it's interesting how quickly some of those expectations change when they
> see you are willing to do so.

Good for you.

Gordon wrote:
> On Dec 12, 1:54 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Gordon wrote:
>>> On Dec 12, 10:15 am, Willem Bogaerts
>>> <w.bogae...@kratz.maardanzonderditstuk.nl> wrote:
>>>>> One major requirement is for the redirection to be invisible to the
>>>>> user, ie that if they visitwww.foo.com/path/document.htmltheywill
>>>>> actually be served content fromwww.bar.com/butthe URL in their
>>>>> browser window will still readwww.foo.com/path/document.html
>>>> I would not do that. Silly remark maybe, but instead ofwww.bar.com, I
>>>> would use something like cms.foo.com. What you are suggesting really
>>>> smells like an attack, even if it isn't.
>>> The thing is that the core server doesn't run PHP and the bosses don't
>>> want PHP on that server on the grounds that it adds a potential avenue
>>> for attack.
>> So what are they using for their OS Commerce? ASP or .NET? PHP is used
>> on millions of sites world wide. If it's installed and configured
>> properly, any security problems are going to be from scripts. But
>> that's typically the weakest point in any language.
>
> It's using a system based on a server side Java engine. I can't talk
> a great deal about it because I honestly don't know a great deal about
> it. It's maintained by a group of developers contracted to the
> company. They want to keep the server locked down as tight as humanly
> possible, so nothing goes on the servers other than the java eCommerce
> engine, and the pages we design for it that are run through a template
> engine server side (think Smarty).
>

IOW they are trying to cover their ignorance and incompetence.

>>> It would also mean that the CMS would have to be
>>> installed for every site it was planned to be used with, and that all
>>> the sales staff would need logins for each instance of the CMS.
>> Sure, it would need to be installed. Big deal. Package everything -
>> Apache, PHP, your CMS, etc. together, write an InstallShield script for
>> it and send out the CD.
>
> I'm pretty sure the eCommerce boxes don't run Windows, and we're not
> allowed to install things on them. It's a rather big business, we
> can't afford to down a server because of faulty software or a security
> breach, and the fewer scripting engines and other software the server
> is running the less chance of that. Like I said, one requirement is
> the potential ownage of the box running the CMS will not affect the
> core eCommerce site. In addition to lost business there is also Data
> Protection Act compliance to take into account. The main eCommerce
> machines hold sensitive information about our customers (names,
> addresses, credit card data if they agree to allowing us to store it,
> purchase history, etc). If that information was exposed the
> ramifications would be enormous.
>

There are equivalents for Linux and other versions of Unix. But they
are again showing their incompetence. If you have a CMS which accesses
the site, then that CMS is also a potential security breach. And
probably a much greater one than if it were installed on the system
itself. Now you have TWO systems, either of which can be breached, and
can cause problems.


> We are most definitely not running osCommerce, and no remotely serious
> eCommerce business should either.
>

I don't think I ever said anything about osCommerce. But it is a decent
package.

>> And even if it's on another server, they will still need to log in.
>>
>>> They're not exactly the sharpest tools in the shed when it comes to
>>> technical stuff.
>> It only takes one competent person to do it. And it could be installed
>> and maintained remotely.
>
> And it only takes 100 incompetent ones emailing our department every
> day with inane questions to kill our department's productivity. :)
>

And what about the 500 incompetent ones emailing your department daily
because of the hoops you have to run through?

>>>>> Can anyone help with this?
>>>> I would tell this story to your system administrators. They might be
>>>> able to configure a "load-balance-like" situation in such a way thatwww.foo.com/ishandled by a different server thanwww.foo.com/cms/
>>>> If the redirection really has to be invisible, you should configure such
>>>> a situation on your own network or server.
>>> That would be nice but unfortunately I'm working in a rather large,
>>> beaurocratic organization where getting other departments to do things
>>> for you can be difficult ant take up a lot of time. Setting up a
>>> proxypass on the main server to the CMS server is just a whole lot
>>> less hassle than getting IS to do things like setting up new
>>> subdomains and servers.
>> Which still doesn't make your solution the correct one. Nor does it
>> make the requirements placed on you reasonable.
>
> Maybe it's not strictly speaking correct or elegant, but it's also
> what I have to work with and that's that. No amount of complaining is
> going to change how the organization works.
>

On something like that, I'd run as fast as I could. Even if it meant
finding another job. Seriously. Because you WILL get the blame when
something goes wrong, even if it isn't your fault.

Question - if you install the CMS on another server - how do you expect
to be able to update the live sites? There has to be access from one to
the other, and that in itself is a possible security problem, even if
it's on a VPN.

>> BTW - that's why I got into consulting - I got tired of this crap. Now
>> if they try to give me unreasonable expectations I can walk away. And
>> it's interesting how quickly some of those expectations change when they
>> see you are willing to do so.
>
> Good for you.
>


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

> > It's using a system based on a server side Java engine. I can't talk
> > a great deal about it because I honestly don't know a great deal about
> > it. It's maintained by a group of developers contracted to the
> > company. They want to keep the server locked down as tight as humanly
> > possible, so nothing goes on the servers other than the java eCommerce
> > engine, and the pages we design for it that are run through a template
> > engine server side (think Smarty).
>
> IOW they are trying to cover their ignorance and incompetence.

No, it's actually a perfectly sensible strategy. The CMS is
completely segregated from the site running the eCommerce engine, and
it only gives the appearance of CMS content being hosted on the
eCommerce site because the main site proxies requests for CMS content
onto the CMS server. The big advantage of this is that each server
only has to run one package (the CMS or the eCommerce software), and
support software (PHP or Java) so there is no way a vuln in the CMS or
in PHP itself can cause damage to the eCommerce sites.

It's a big business, and has bricks-and-mortar stores as well as an
eCommerce site. The back end software has to support terminals in the
bricks-and-mortar stores as well as the eCommerce sites we run. The
company is not going to change it's entire infrastructure just for a
CMS.

> > I'm pretty sure the eCommerce boxes don't run Windows, and we're not
> > allowed to install things on them. It's a rather big business, we
> > can't afford to down a server because of faulty software or a security
> > breach, and the fewer scripting engines and other software the server
> > is running the less chance of that. Like I said, one requirement is
> > the potential ownage of the box running the CMS will not affect the
> > core eCommerce site. In addition to lost business there is also Data
> > Protection Act compliance to take into account. The main eCommerce
> > machines hold sensitive information about our customers (names,
> > addresses, credit card data if they agree to allowing us to store it,
> > purchase history, etc). If that information was exposed the
> > ramifications would be enormous.
>
> There are equivalents for Linux and other versions of Unix. But they
> are again showing their incompetence. If you have a CMS which accesses
> the site, then that CMS is also a potential security breach. And
> probably a much greater one than if it were installed on the system
> itself. Now you have TWO systems, either of which can be breached, and
> can cause problems.

That's the whole point, the CMS *doesn't* access the ecommerce site!
The only way in which they are connected is that the eCommerce site
will proxy requests for CMS content onto the CMS server. That way the
absolute worst thing that can happen if the CMS is compromised is that
its content is destroyed or vandalized and the main eCommerce site
carries on happily. If the CMS was hosted on the eCommerce server
itself and was compromised the consequences would be far more dire.

> > And it only takes 100 incompetent ones emailing our department every
> > day with inane questions to kill our department's productivity. :)
>
> And what about the 500 incompetent ones emailing your department daily
> because of the hoops you have to run through?

They are only setting requirements regarding user interface, and that
basically boils down to "must look pretty and have instructions
printed on drool-proof paper". They're sales guys, I've never met a
sales guy who really "got" computers. The technical requirements are
being set by ourselves and by our partners who run the eCommerce
software.

> > Maybe it's not strictly speaking correct or elegant, but it's also
> > what I have to work with and that's that. No amount of complaining is
> > going to change how the organization works.
>
> On something like that, I'd run as fast as I could. Even if it meant
> finding another job. Seriously. Because you WILL get the blame when
> something goes wrong, even if it isn't your fault.

Jobs must be really really easy to come by where you live. That's not
the case here. And the fact that my eyesight is too poor to allow me
to obtain a drivers' license narrows my opportunities even further.
Besides, I like working where I am, the team I work in is a good one,
while dealing with other departments isn't fun I fortunately don't
have to do so very often.

> Question - if you install the CMS on another server - how do you expect
> to be able to update the live sites? There has to be access from one to
> the other, and that in itself is a possible security problem, even if
> it's on a VPN.

The live sites proxy onto the CMS. I have a feeling that this is the
critical piece of information that you might have missed and I guess
that's what's causing your confusion over what I'm trying to achieve.
The CMS will need to know which eCommerce site the request originated
from so it knows the hierarchy to start searching through.
REQUEST_URI only seems to contain the path and the host name data is
lost.

Gordon wrote:
>>> It's using a system based on a server side Java engine. I can't talk
>>> a great deal about it because I honestly don't know a great deal about
>>> it. It's maintained by a group of developers contracted to the
>>> company. They want to keep the server locked down as tight as humanly
>>> possible, so nothing goes on the servers other than the java eCommerce
>>> engine, and the pages we design for it that are run through a template
>>> engine server side (think Smarty).
>> IOW they are trying to cover their ignorance and incompetence.
>
> No, it's actually a perfectly sensible strategy. The CMS is
> completely segregated from the site running the eCommerce engine, and
> it only gives the appearance of CMS content being hosted on the
> eCommerce site because the main site proxies requests for CMS content
> onto the CMS server. The big advantage of this is that each server
> only has to run one package (the CMS or the eCommerce software), and
> support software (PHP or Java) so there is no way a vuln in the CMS or
> in PHP itself can cause damage to the eCommerce sites.
>

Not sensible at all. PHP itself is NOT insecure - any more than Java or
anything else it. Only scripts written by people who are not familiar
with security considerations are insecure.

> It's a big business, and has bricks-and-mortar stores as well as an
> eCommerce site. The back end software has to support terminals in the
> bricks-and-mortar stores as well as the eCommerce sites we run. The
> company is not going to change it's entire infrastructure just for a
> CMS.
>

OK, so it's a big business. And rather than design a system the right
way, they're going to cobble together a bunch of stuff and hope it works.

>>> I'm pretty sure the eCommerce boxes don't run Windows, and we're not
>>> allowed to install things on them. It's a rather big business, we
>>> can't afford to down a server because of faulty software or a security
>>> breach, and the fewer scripting engines and other software the server
>>> is running the less chance of that. Like I said, one requirement is
>>> the potential ownage of the box running the CMS will not affect the
>>> core eCommerce site. In addition to lost business there is also Data
>>> Protection Act compliance to take into account. The main eCommerce
>>> machines hold sensitive information about our customers (names,
>>> addresses, credit card data if they agree to allowing us to store it,
>>> purchase history, etc). If that information was exposed the
>>> ramifications would be enormous.
>> There are equivalents for Linux and other versions of Unix. But they
>> are again showing their incompetence. If you have a CMS which accesses
>> the site, then that CMS is also a potential security breach. And
>> probably a much greater one than if it were installed on the system
>> itself. Now you have TWO systems, either of which can be breached, and
>> can cause problems.
>
> That's the whole point, the CMS *doesn't* access the ecommerce site!
> The only way in which they are connected is that the eCommerce site
> will proxy requests for CMS content onto the CMS server. That way the
> absolute worst thing that can happen if the CMS is compromised is that
> its content is destroyed or vandalized and the main eCommerce site
> carries on happily. If the CMS was hosted on the eCommerce server
> itself and was compromised the consequences would be far more dire.
>

OK, so their site is now going to depend on two (or more) servers being
up. And if either (or any) of the servers is down, they're up the
proverbial creek.

Makes sense to me - NOT.

>>> And it only takes 100 incompetent ones emailing our department every
>>> day with inane questions to kill our department's productivity. :)
>> And what about the 500 incompetent ones emailing your department daily
>> because of the hoops you have to run through?
>
> They are only setting requirements regarding user interface, and that
> basically boils down to "must look pretty and have instructions
> printed on drool-proof paper". They're sales guys, I've never met a
> sales guy who really "got" computers. The technical requirements are
> being set by ourselves and by our partners who run the eCommerce
> software.
>

I've never met a sales guy who "gets" anything. Most are there because
they can't do anything else - even teach.

As you can tell, I have a high opinion of sales people :-)

>>> Maybe it's not strictly speaking correct or elegant, but it's also
>>> what I have to work with and that's that. No amount of complaining is
>>> going to change how the organization works.
>> On something like that, I'd run as fast as I could. Even if it meant
>> finding another job. Seriously. Because you WILL get the blame when
>> something goes wrong, even if it isn't your fault.
>
> Jobs must be really really easy to come by where you live. That's not
> the case here. And the fact that my eyesight is too poor to allow me
> to obtain a drivers' license narrows my opportunities even further.
> Besides, I like working where I am, the team I work in is a good one,
> while dealing with other departments isn't fun I fortunately don't
> have to do so very often.
>

Not at all easy. At least not good jobs.

But this one is a huge trap waiting to spring. And guess who's the
bait? It sure isn't the sales guys or the people running the Java server.

>> Question - if you install the CMS on another server - how do you expect
>> to be able to update the live sites? There has to be access from one to
>> the other, and that in itself is a possible security problem, even if
>> it's on a VPN.
>
> The live sites proxy onto the CMS. I have a feeling that this is the
> critical piece of information that you might have missed and I guess
> that's what's causing your confusion over what I'm trying to achieve.
> The CMS will need to know which eCommerce site the request originated
> from so it knows the hierarchy to start searching through.
> REQUEST_URI only seems to contain the path and the host name data is
> lost.
>

OK, yes, I missed that one.

And yes, the REQUEST_URI only contains the resource, not the host. You
might try $_SERVER['HTTP_HOST'], but if they're just proxying, it should
have your host in it. It just depends on how they're doing it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Dec 13, 5:03 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:

> Not sensible at all. PHP itself is NOT insecure - any more than Java or
> anything else it. Only scripts written by people who are not familiar
> with security considerations are insecure.

By having 2 different scripting engines on a site you have 2 vectors
for attack. No software is 100% secure, and whenever a PHP vuln is
unearthed it tends to circulate widely. You're right to say that PHP
is no more or less secure than Java, but in the web server sphere at
least PHP is far more visible. Anyone attempting to crack the server
is probably going to start with exploiting PHP for the simple reason
that it is more high profile.

> OK, so it's a big business. And rather than design a system the right
> way, they're going to cobble together a bunch of stuff and hope it works.

That's how it is with big businesses, they are all built on multiple
systems that have to coexist. That's simply reality and no amount of
arguing is ever going to change that.

> > That's the whole point, the CMS *doesn't* access the ecommerce site!
> > The only way in which they are connected is that the eCommerce site
> > will proxy requests for CMS content onto the CMS server. That way the
> > absolute worst thing that can happen if the CMS is compromised is that
> > its content is destroyed or vandalized and the main eCommerce site
> > carries on happily. If the CMS was hosted on the eCommerce server
> > itself and was compromised the consequences would be far more dire.
>
> OK, so their site is now going to depend on two (or more) servers being
> up. And if either (or any) of the servers is down, they're up the
> proverbial creek.
>
> Makes sense to me - NOT.

The eCommerce portion of the site is mission critical and must not go
down. The CMS is dispensable, if it goes down it's an inconvenience
but not the end of the world. For example I took the server the CMS
runs on down for the day to upgrade to a newer Apache and PHP.
Business on the eCommerce site continued as usual. By having them on
seperate servers the eCommerce server is isolated from problems that
might occur on the CMS server.

> I've never met a sales guy who "gets" anything. Most are there because
> they can't do anything else - even teach.
>
> As you can tell, I have a high opinion of sales people :-)

Ditto!

> > Jobs must be really really easy to come by where you live. That's not
> > the case here. And the fact that my eyesight is too poor to allow me
> > to obtain a drivers' license narrows my opportunities even further.
> > Besides, I like working where I am, the team I work in is a good one,
> > while dealing with other departments isn't fun I fortunately don't
> > have to do so very often.
>
> Not at all easy. At least not good jobs.
>
> But this one is a huge trap waiting to spring. And guess who's the
> bait? It sure isn't the sales guys or the people running the Java server.

We don't play the blame game in our department. My line managers are
good people, I've had plenty of experience of dealing with ones that
aren't to know that the senario you're talking about simply isn't
going to happen. In fact I'm still wondering how my simple request
for help with what I thought was a fairly minor problem has turned
into such a massive debate about working conditions.

> > The live sites proxy onto the CMS. I have a feeling that this is the
> > critical piece of information that you might have missed and I guess
> > that's what's causing your confusion over what I'm trying to achieve.
> > The CMS will need to know which eCommerce site the request originated
> > from so it knows the hierarchy to start searching through.
> > REQUEST_URI only seems to contain the path and the host name data is
> > lost.
>
> OK, yes, I missed that one.
>
> And yes, the REQUEST_URI only contains the resource, not the host. You
> might try $_SERVER['HTTP_HOST'], but if they're just proxying, it should
> have your host in it. It just depends on how they're doing it.

Okay, now we're getting somewhere :) I hadn't looked into HTTP_HOST
on the grounds that I had assumed it contained the hostname of the
server the PHPcript was executing on. I'll try experiemnting with
it.

I believe the proxying is being done with proxypass directives on the
web server that's running the ecommerce site.

Gordon wrote:
> On Dec 13, 5:03 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>
>> Not sensible at all. PHP itself is NOT insecure - any more than Java or
>> anything else it. Only scripts written by people who are not familiar
>> with security considerations are insecure.
>
> By having 2 different scripting engines on a site you have 2 vectors
> for attack. No software is 100% secure, and whenever a PHP vuln is
> unearthed it tends to circulate widely. You're right to say that PHP
> is no more or less secure than Java, but in the web server sphere at
> least PHP is far more visible. Anyone attempting to crack the server
> is probably going to start with exploiting PHP for the simple reason
> that it is more high profile.
>

Only if you've configured them incorrectly and/or have programmers who
are not aware of security exposures. And PHP is quite secure - the
people at Zend take security very seriously.

>> OK, so it's a big business. And rather than design a system the right
>> way, they're going to cobble together a bunch of stuff and hope it works.
>
> That's how it is with big businesses, they are all built on multiple
> systems that have to coexist. That's simply reality and no amount of
> arguing is ever going to change that.
>

No, it isn't. Most of my customers are Fortune 500 companies - every
one you would easily recognize. And yes, while they have multiple
systems, they do not cobble some abortion like this together, especially
because some incompetent group claims that's the way it must be.

If there were a need for multiple systems like you claim is required,
there would have to be a huge amount of documentation proving how
security would be compromised. They do not take the word of a few
people when betting their business on something. Especially a few
people who have no idea what they're talking about (Java programmers
talking about PHP in this case).

>>> That's the whole point, the CMS *doesn't* access the ecommerce site!
>>> The only way in which they are connected is that the eCommerce site
>>> will proxy requests for CMS content onto the CMS server. That way the
>>> absolute worst thing that can happen if the CMS is compromised is that
>>> its content is destroyed or vandalized and the main eCommerce site
>>> carries on happily. If the CMS was hosted on the eCommerce server
>>> itself and was compromised the consequences would be far more dire.
>> OK, so their site is now going to depend on two (or more) servers being
>> up. And if either (or any) of the servers is down, they're up the
>> proverbial creek.
>>
>> Makes sense to me - NOT.
>
> The eCommerce portion of the site is mission critical and must not go
> down. The CMS is dispensable, if it goes down it's an inconvenience
> but not the end of the world. For example I took the server the CMS
> runs on down for the day to upgrade to a newer Apache and PHP.
> Business on the eCommerce site continued as usual. By having them on
> seperate servers the eCommerce server is isolated from problems that
> might occur on the CMS server.
>

As it is for a huge number of companies. In fact, some of the biggest
companies in the world get a significant amount of sales through their
web sites. Now they won't go bankrupt if there's a problem - but in
many cases you're talking income in the 100's of millions of dollars per
year.

That's not peanuts. And they can't afford to have their sites compromised.

>> I've never met a sales guy who "gets" anything. Most are there because
>> they can't do anything else - even teach.
>>
>> As you can tell, I have a high opinion of sales people :-)
>
> Ditto!
>
>>> Jobs must be really really easy to come by where you live. That's not
>>> the case here. And the fact that my eyesight is too poor to allow me
>>> to obtain a drivers' license narrows my opportunities even further.
>>> Besides, I like working where I am, the team I work in is a good one,
>>> while dealing with other departments isn't fun I fortunately don't
>>> have to do so very often.
>> Not at all easy. At least not good jobs.
>>
>> But this one is a huge trap waiting to spring. And guess who's the
>> bait? It sure isn't the sales guys or the people running the Java server.
>
> We don't play the blame game in our department. My line managers are
> good people, I've had plenty of experience of dealing with ones that
> aren't to know that the senario you're talking about simply isn't
> going to happen. In fact I'm still wondering how my simple request
> for help with what I thought was a fairly minor problem has turned
> into such a massive debate about working conditions.
>

No, but you will get the blame in the company. Every company I've ever
seen which creates unrealistic demands needs someone to blame when those
demands aren't met.

And then the PTB come down on your department, is your line manager
going to take the blame and possibly get fired, or pass it on?

This is not a minor request for help. It is a hellhole. And it's
exactly the type of job I refuse.


>>> The live sites proxy onto the CMS. I have a feeling that this is the
>>> critical piece of information that you might have missed and I guess
>>> that's what's causing your confusion over what I'm trying to achieve.
>>> The CMS will need to know which eCommerce site the request originated
>>> from so it knows the hierarchy to start searching through.
>>> REQUEST_URI only seems to contain the path and the host name data is
>>> lost.
>> OK, yes, I missed that one.
>>
>> And yes, the REQUEST_URI only contains the resource, not the host. You
>> might try $_SERVER['HTTP_HOST'], but if they're just proxying, it should
>> have your host in it. It just depends on how they're doing it.
>
> Okay, now we're getting somewhere :) I hadn't looked into HTTP_HOST
> on the grounds that I had assumed it contained the hostname of the
> server the PHPcript was executing on. I'll try experiemnting with
> it.
>
> I believe the proxying is being done with proxypass directives on the
> web server that's running the ecommerce site.
>

Then you're probably going to be SOL.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================