|
midrange.com
Brad,
Wow. You've come to my rescue twice in one week. I might just have to put
you on my Christmas card list this year. <g> If you haven't guessed I'm
new to this stuff (but learning fast). I wouldn't have guessed it but
passing the cookie info back and forth does make sense as a method of
"logging in".
So, in my situation where it redirects from A to B to C back to A then I
should probably look for the cookie in the header when going from A to B
then pass it back when posting to B and hope that I get redirected to D
instead of C, correct? I'll have to keep an eye on what the values are
when I debug it a few times.
I'll give it a shot and see what happens. Thanks!
Dave Parnin
Nishikawa Standard Company
Topeka, IN 46571
daparnin@xxxxxxxxxxxxxxxxxx
Brad Stone
<brad@xxxxxxxxxxx To: Web Enabling the AS400
/ iSeries
m> <web400@xxxxxxxxxxxx>@SMTP@CTB
Sent by: cc: (bcc: David A
Parnin/Topeka/NISCO/SPCO)
web400-bounces@mi Subject: Re: [WEB400] 302
Redirection Headaches
drange.com
07/30/2004 01:39
PM
Please respond to
Web Enabling the
AS400 / iSeries
<web400@midrange.
com>
They're most likely using frames... so what you need to do
is view the source for the page with the input fields on
it, and do a POST to the path specified in the form on the
action tag sending along the appropriate data fields
(hidden or not). I doubt you'd use the API or any other
tool to go to a root domain.
After "logging in" many times you will be returned either a
cookie or a session ID. That needs to be saved and sent in
the header of any subsequent request so it thinks you're
still "logged on". Sometimes apps can be picky as to how
te headers with cookie/session data are returned, so it
will take some time.
I've helped many customers in similar scenarios do this
exact same thing with my GETURI application. Some use
cookies, some use session IDs. Either have to be parsed
from the returned header for later use in following
requests.
Bradley V. Stone
www.bvstools.com
Brad
On Fri, 30 Jul 2004 12:45:49 -0500
daparnin@xxxxxxxxxxxxxxxxxx wrote:
>
>
>
>
> Good morning,
>
> I'm trying to adapt Scott Klement's HTTPAPI code to send
> a file to our
> bank. The digital certificate hurdle has been jumped but
> now I'm facing a
> seemingly endless 302 redirect problem. Ultimately I
> want to use Scott's
> http_url_post() routine to fill in a box with a file name
> but have been
> playing with the http_url_get() to try to resolve the
> redirection problem
> so I can get to that point.
>
> The scenario goes like this:
> When I connect to http://www.bank.com/ it returns a 302
> redirecting me to
> http://www.bank.com/a. When I connect to
> http://www.bank.com/a it returns
> a 302 redirecting me to http://www.bank.com/b. When I
> connect to that it
> gives me a 302 that sends me back to
> http://www.bank.com/. Argh!!!! How
> do I debug this? I've looked at the files in /tmp but
> nothing has jumped
> out at me.
>
> >From a browser perspective I connect to
> http://www.bank.com, click the
> login/logout button, and am taken to the page that I want
> to get to however
> the address in the browser's address box doesn't change.
> How can I tell
> where my browser is pointed other than the address bar
> and viewing the
> source of the initial page? Any thoughts?
>
> Dave Parnin
> Nishikawa Standard Company
> Topeka, IN 46571
> daparnin@xxxxxxxxxxxxxxxxxx
>
>
> HTML Source for first page:
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <TITLE>Logged In</TITLE>
> </HEAD>
> <BODY>
> <CENTER><A HREF="/"
> onMouseOver="window.status='Continue';return true"><IMG
> SRC="/icons/stlogo.gif" BORDER=0
> ALT="Continue"></A></CENTER>
> <BR>
> <HTML><P>
> WARNING! You have accessed a private computer system...
> blah, blah,
> blah...
> </P></HTML>
> <BR>
> </BODY>
> </HTML>
>
>
>
>
> _______________________________________________
> This is the Web Enabling the AS400 / iSeries (WEB400)
> mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/web400.
>
Bradley V. Stone
BVS.Tools
www.bvstools.com
_______________________________________________
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
