Getting complete URL after a redirect

On Dec 14, 1:38 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:

(snip)

You've obviously got a massive chip on your shoulder so I think I'm
pretty much giving up trying to listen to or reason with you. I've
done my best to be polite and patient and to explain the programming
problem I need to solve and instead of offering any help you basically
just launch an attack on my employers. You've been rude and
condescending and an expert on telling me what to do about everything
except the thing I asked for help with in the first place. If your
interpersonal skills are really as utterly pathetic as is coming
across in your posts then it's no wonder you constantly feel the need
to throw a tantrum and walk out on jobs the instant you're expected to
make any kind of compromise whatsoever.

Gordon wrote:
> On Dec 14, 1:38 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>
> (snip)
>
> You've obviously got a massive chip on your shoulder so I think I'm
> pretty much giving up trying to listen to or reason with you. I've
> done my best to be polite and patient and to explain the programming
> problem I need to solve and instead of offering any help you basically
> just launch an attack on my employers. You've been rude and
> condescending and an expert on telling me what to do about everything
> except the thing I asked for help with in the first place. If your
> interpersonal skills are really as utterly pathetic as is coming
> across in your posts then it's no wonder you constantly feel the need
> to throw a tantrum and walk out on jobs the instant you're expected to
> make any kind of compromise whatsoever.
>

No, I have NO chip on my shoulder. But I do have 40 years of
programming experience, and I've situations very similar to yours.

And I don't "throw a tantrum and walk out on jobs". But I don't take
jobs which are doomed to failure, either.

Every job I have walked away from has failed. Not because I wasn't
there - but because of the very reasons I walked away. I have learned
that saying "no" can be more profitable than saying "yes". And it's
definitely less ulcer-forming.

I have not been rude and condescending, but I have told you what I
thought of your employers.

You don't like it? Quite frankly, I don't care. I was just trying to
show you how stupid such a situation is. But from your updates I also
think you aren't telling the entire story. I suspect you have a lot
more invested in promoting this lousy design than the passive role
you've claimed.

And contrary to your other claim, I have tried to give you assistance on
your technical problem. But as others have tried to tell you, there is
no solution for doing it how you want.

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

On Dec 14, 11:45 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:

> No, I have NO chip on my shoulder. But I do have 40 years of
> programming experience, and I've situations very similar to yours.

Nothing in your 40 years' experience about not coming across like a
smug git, I see.

> Every job I have walked away from has failed.

:)

> I have not been rude and condescending, but I have told you what I
> thought of your employers.

Where did I ask for your opinion of my employers?

> You don't like it? Quite frankly, I don't care. I was just trying to
> show you how stupid such a situation is. But from your updates I also
> think you aren't telling the entire story. I suspect you have a lot
> more invested in promoting this lousy design than the passive role
> you've claimed.

Whatever. For the record, the design requirements already existed
before I was even employed here. But you've obviously already jumped
to your own conclusions so just keep on telling yourself that anything
you're not particularly enamoured with is stupid. and lousy design.
Personally, I think opting for a design that ensures a non-vital
portion of a site can't take down a vital portion isn't lousy and in
fact makes a great deal of sense, but that's just me.

> And contrary to your other claim, I have tried to give you assistance on
> your technical problem. But as others have tried to tell you, there is
> no solution for doing it how you want.

One brief comment about HTTP_HOST doesn't exactly smack of effort in
the trying to help stakes.

I decided to read a few more of the threads you're involved with
because I thought I should give you the benefit of the doubt, that
maybe there's just some horrible clash of personalities going on here,
or that I caught you on a bad day, but it's pretty obvious from the
ones I read that you're completely full of yourself and nobody else
here likes you.

Don't bother replying, I'm not going to read it. In fact, don't
bother replying to any posts I make in here from now on. I don't see
why you should anyway, I'm obviously completely beneath your
contempt. You're certainly beneath mine.

Gordon wrote:
> On Dec 14, 11:45 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>
>> No, I have NO chip on my shoulder. But I do have 40 years of
>> programming experience, and I've situations very similar to yours.
>
> Nothing in your 40 years' experience about not coming across like a
> smug git, I see.
>

Quite frankly, I don't give a damn about what you think. You can't
accept the facts, that's your problem. And your unemployment when they
start looking for someone to blame.

>> Every job I have walked away from has failed.
>
> :)
>
>> I have not been rude and condescending, but I have told you what I
>> thought of your employers.
>
> Where did I ask for your opinion of my employers?
>

Where did it ever say I had to have your permission?

>> You don't like it? Quite frankly, I don't care. I was just trying to
>> show you how stupid such a situation is. But from your updates I also
>> think you aren't telling the entire story. I suspect you have a lot
>> more invested in promoting this lousy design than the passive role
>> you've claimed.
>
> Whatever. For the record, the design requirements already existed
> before I was even employed here. But you've obviously already jumped
> to your own conclusions so just keep on telling yourself that anything
> you're not particularly enamoured with is stupid. and lousy design.
> Personally, I think opting for a design that ensures a non-vital
> portion of a site can't take down a vital portion isn't lousy and in
> fact makes a great deal of sense, but that's just me.
>

No, I've seen similarly lousy designs in the past. I wouldn't know
where to start in listing the potential problems with it. OTOH, good
design and testing will eliminate those problems yet still not be able
to bring down the site.

There are millions of eCommerce sites world wide. The number which
implement such a design is very near zero. There must be a reason.

And now you're changing your story. Earlier in this thread you've
intimated you've been with the company for quite. Now you say the
design requirements existed before you were employed there. Which is it?

Or is it really YOUR design? The way your story is changing, I suspect
the latter.

>> And contrary to your other claim, I have tried to give you assistance on
>> your technical problem. But as others have tried to tell you, there is
>> no solution for doing it how you want.
>
> One brief comment about HTTP_HOST doesn't exactly smack of effort in
> the trying to help stakes.
>

No, I tried a lot more to help you. But you won't listen.

> I decided to read a few more of the threads you're involved with
> because I thought I should give you the benefit of the doubt, that
> maybe there's just some horrible clash of personalities going on here,
> or that I caught you on a bad day, but it's pretty obvious from the
> ones I read that you're completely full of yourself and nobody else
> here likes you.
>

No, I have a lot of programming experience in a lot of different
languages. I make a very good living as a trainer/consultant. And my
customers listen to me because they know I know what I'm talking about.

Also, I don't try to sugar coat anything. If something is great, I tell
them it's great, and why. If something is stupid, I tell them it's
stupid, and why.

> Don't bother replying, I'm not going to read it. In fact, don't
> bother replying to any posts I make in here from now on. I don't see
> why you should anyway, I'm obviously completely beneath your
> contempt. You're certainly beneath mine.
>

Quite frankly, I don't give a shit about your opinion. There are quite
a few people here who like me. But I will call a troll a troll. And I
will say a design is stupid when I think a design is stupid.

But you've made this very clear. You're promoting a shitty design and
now are trying to make it work. Good luck.

And unfortunately, it's guys like you who give programmers a bad reputation.

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

On Dec 12, 9:55 am, Gordon <gordon.mc...@ntlworld.com> wrote:
> 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 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
>
> 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?

Seems that when proxying the server being proxied to will expose a
couple of headers that hold the name of the originating server,
called http-x-forwarded-host and http-x-forwarded-server which I can
use to determine the originating site.

Gordon,

Is hiding where it comes from good enough? For instance what if
http://www.foo.com/path/document.html
includes an <iframe src="www.bar.com/path/document.html">

I tend to suggest that as a solution because for redirection to work
you must send a header that gets processed *first*, and using post
tends to cause all other header directives to be ignored (that are not
directly related to the post (size in bytes, what operations are
permitted by filetype, etc)).

It's not gonna stop a true hacker but they'd have to work a bit more.

>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.

In some organizations which are really serious about security
(military), you need to have a huge amount of documentation on any
new thing proving how security would *NOT* be compromised. Until
you have it, you're not allowed to connect it to the network. (This
makes setting up new systems a bit problematic as you can't use
normal online update procedures since it needs to be patched *before*
you put it online.) And you'll have to document everything it wants
to do with every other system (even inside systems) or it won't get
through the router. Want ping? You probably won't be able to
justify it. System A needs to proxy for system B? Document it or
the packets won't go through.

>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.

It seems reasonable to separate systems with incompatible requirements
for downtime. For example, if it requires any downtime to install the
CMS, that alone might disqualify it from being shared with the eCommerce
server.

>> 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.

I don't think your problem has a solution involving getting the
full URL. You can't modify the proxy for political reasons, and
information that isn't there can't be pulled out of a (CMS) server's
ass. Modern servers come ass-less. The CMS server simply never
gets the information, and PHP running on that server can't do
anything about that.

How many possible domain names in URLs *are* there to get, if you
could get them? If the number is small, consider one CMS machine
per domain name. If it's on *this* machine, it must originally
have been for *that* URL. This requires modifying the proxy, but
it likely requires only duplicating portions of a configuration
file, not making it add a whole new header.

There's another possibility, which gets you back to one CMS machine.
$_SERVER['HTTP_HOST'] gives you the content of the Host: header.
That's the domain name of the CMS server. But there's nothing
prohibiting you from assigning more than one domain to the CMS
server, say, one for each eCommerce store. (This requires DNS
entries, and web server configuration). In that case, you get
*which* CMS domain name was sent in the Host: header. Set up the
proxy to send requests for eCommerce store <a> to the CMS domain
name for <a>. Now, the CMS, given a configuration table, can find
the CMS domain name from $_SERVER['HTTP_HOST'], and translate it
back to the eCommerce domain name.

To do this, you need:
(1) an eCommerce domain name (e.g. pornmasterbait.com, name of the
customer who sells earthworm porn) and a CMS domain name (e.g.
pornmasterbait.cms.eCommerceservice.com, name of your company that
gets paid for running stores) per store. (The CMS domain name
needn't be a top-level domain and it shouldn't be visible to
customers).
(2) Web-server configuration on the CMS server per store.
(3) Configuration on the eCommerce proxy server to send CMS requests for
each store to the corresponding CMS domain name for each store.
(4) Some kind of configuration, maybe in a database, to let the CMS app
translate CMS domain names back to eCommerce domain names.


>>>> 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 proxy probably doesn't (possibly *can't*, without code, as
opposed to configuration changes) include the information you need
in the forwarded requests.

>>>> The CMS will need to know which eCommerce site the request originated
>>>> from so it knows the hierarchy to start searching through.

How about one eCommerce site, one CMS? Or does that take too many machines?
Or one eCommerce site, one CMS virtual webserver?

>> 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.

It does, but there can be more than one such name.

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