Michael A. Stone writes:
> > I don't know why, but it seems lately most of my posts get
> >misunderstood :-(. Yes, doing a Location: redirect with a GET query
> >string is fairly easy, but what I need is a redirect such that the
> >browser POSTs to the second server.
>
> in that case, the short answer is: "you can't".
That's what I was afraid of. Sigh.
> if you explicitly need a second POST query from the browser,
> you're out of luck. it can't be done without a second click
> from the user's mouse. AFAIK, even Java and Javascript won't
> help you, because to do so would leave an opening for all sorts
> of security problems.
Javascript isn't my forte (nor do I want it to be) but a friend
has advised me that it should be possible t have the CGI, instead of
issuing a redirect header, generate a page with a form, and the values
already filled in, and a javascript OnLoad function to automatically
submit the form (which would be pointed at the second site). I'll be
testing this later today or tomorrow morning.
Keep in mind that in this case, although they are different
servers, they have the same root domain. In fact, the first server is
something like blah.com and the second server is something like
more.blah.com. I don't know offhand if this will have security
implications for javascript as it does for cookies.
> [...excellent discussion of HTTP client/server interaction and
> MIME protocol deleted ...]
Thanks, this was just what I needed to learn about. I had been
planning to go pick up _Web Client Programming_ (Clinton Wong,
O'Reilly Associates) over lunch, and I probably still will, but you've
already answered most of my immediate questions.
> failing the impossible and the terminally (with any luck)
> careless, you have three remaining options:
>
> 1. make the user click the submit button a second time
> 2. pass the information directly from server A to server B
> 3. use a redirected GET query with an extension
>
> as i understood your original question, the whole purpose of
> attempting a reflected POST was to avoid #1, and neither of the
Yup, although the circumstances are more the reverse - we already
ask the user to click on a login button, we want to grab that login
info without asking them to do it again.
> remaining options is really a reflected POST. #2 involves
> synchronization and session control issues, which means that any
> working solution will be fairly complex.
Yeah, this gets really hairy, although I *gotta* wonder if
Livewire might have stuff to support most of what we need, since
Netscape invented the critical bits (mainly having the Livewire do a
128-bit SSL encrypted post to our server). Anybody know any Livewire
gurus?
The alternative, which would be hairy but probably doable, is
building essentially a proxy server that takes the request, proxies it
out to the second site, takes the cookie that the second site sets in
response and pass it back to the browser along with a vanilla redirect
to the second site.
> #3 is simpler, so that's the one i mentioned.
Yup, unfortunately it has problems (which I'll talk about below).
> to back up a step or two, what specifically makes a reflected
> POST desirable/necessary in your current situation? the
> difference in terms of data transfer bewteen a GET and a POST is
> negligible as far as the script at the back end is concerned,
> and the input data itself is identical. what additional
> feature of the POST method makes the difference between:
There are the security issues, as mentioned last message; GET
requests can be bookmarked and resubmitted, etc. Unfortunately this
is a very high security context (for the same reasons, I have to be a
bit vague about organization names, etc). Additionally, while the
servers are both owned and operated by the same organization, for
organizational/political reasons we can't make major changes on the
second server (well, we could, with about 18 months of committee
meetings involving a couple dozen equally sized organizations....).
These two factors combine as well; the security consciousness
means it's very likely that the receiving system will just freak out
because it's receiving a GET request instead a POST request. The
CGI-based redirect to a URL with a query string attached hung for a
while and then got me a "forbidden" message. I still need to go test
that (which I will do as soon as I send this message) by invoking the
original login process directly via a form that is identical except
for using GET instead of POST.
Steven J. Owens
[EMAIL PROTECTED]
____________________________________________________________________
--------------------------------------------------------------------
Join The NEW Web Consultants Association FORUMS and CHAT:
Register Today at: http://just4u.com/forums/
Web Consultants Web Site : http://just4u.com/webconsultants
Give the Gift of Life This Year...
Just4U Stop Smoking Support forum - helping smokers for
over three years-tell a friend: http://just4u.com/forums/
To get 500 Banner Ads for FREE
go to http://www.linkbuddies.com/start.go?id=111261
---------------------------------------------------------------------
