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