hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ROLWE...@de.ibm.com>
Subject Re: POST Form Session Expired
Date Sat, 10 Sep 2005 09:16:33 GMT
Hi Jeremy,

I'm sorry I don't have the time to dig into this.
>From a quick glance, I'd say that the combination
of different server names and relative redirects
might have shaken you off the path. RFC 2616
doesn't allow relative redirect locations, but
nobody seems to care. So when you evaluate
a Location: header with a relative path, make sure
you do that with the server to which the request
was actually sent.

Since your workaround works, you should go
with it. The request with the credentials establishes
the session, and afterwards you can freely navigate.
The redirect is just supposed to tell the browser
which is the entry page after login. If you're
reasonably sure that this page is not going to
change, then you don't have to read it from the
response.

hope that helps,
  Roland




Jeremy Whitlock <jcscoobyrs@gmail.com> 
09.09.2005 17:51
Please respond to
"HttpClient User Discussion"


To
HttpClient User Discussion <httpclient-user@jakarta.apache.org>
cc

Subject
Re: POST Form Session Expired






Roland,
I actually took a slightly different approach. Based on my feedback from 
Live Headers:

#request# POST 
http://profile1.bea.com/shared_services/login/login.do;SHARED_SERVICES_SESSION=Dh8yKynv3FncslMdvhpTVmR7Q3H7mVV1KX2tw9p2RL5xgmXdyCbg!-1169276618!1598972357

POST 
/shared_services/login/login.do;SHARED_SERVICES_SESSION=Dh8yKynv3FncslMdvhpTVmR7Q3H7mVV1KX2tw9p2RL5xgmXdyCbg!-1169276618!1598972357
headerPath=%2Fhomepage%2Fheader_eis.html&footerPath=%2Fhomepage%2Ffooter_eis.html&navbarPath=%2Fhomepage%2Fnavbar_eis.html&returnURL=%2Flwsetter&webappURL=http%3A%2F%2Fentry-
prodtest.bea.com&contentURL=http%3A%2F%2Fentry.bea.com&callingApp=Dev2Dev&stylesheetPath=%2Fhomepage%2Ffonts.css&action=login&support_url=http%3A%2F%2Fwww.bea.com%2Fframework.jsp%3FCNT%3Dindex.htm%26FP%3D%2Fcontent%2Fservices%2Fcustomer_support%2Fcontacts%2F&support_url_text=Contact+the+BEA+Support+Team&%7BactionForm.username%7D=MYUSERNAME&%7BactionForm.password%7D=MYPASSWORD
#request# GET 
http://entry-prodtest.bea.com//ss_client?action=login&returnURL=%2Flwsetter&ssReturnCode=0000

#redirect# GET 
//ss_client?action=login&returnURL=%2Flwsetter&ssReturnCode=0000
#request# GET http://entry-prodtest.bea.com/lwsetter
#redirect# GET /lwsetter
#request# GET https://www.projects.dev2dev.bea.com/servlets/StartPage
#redirect# GET /servlets/StartPage
#request# GET 
http://entry.bea.com/lwsetter?eisal=true&vdest=https://www.projects.dev2dev.bea.com/servlets/StartPage

#redirect# GET /lwsetter?eisal=true&vdest=
https://www.projects.dev2dev.bea.com/servlets/StartPage
#request# GET https://www.projects.dev2dev.bea.com/servlets/StartPage
#redirect# GET /servlets/StartPage
#request# GET https://www.projects.dev2dev.bea.com/servlets/StartPage
#redirect# GET /servlets/StartPage
#request# GET https://www.projects.dev2dev.bea.com/branding/css/tigris.css
#request# GET https://www.projects.dev2dev.bea.com/branding/css/inst.css
#request# GET https://www.projects.dev2dev.bea.com/branding/css/print.css
#request# GET 
https://www.projects.dev2dev.bea.com/branding/scripts/tigris.js
#request# GET https://www.projects.dev2dev.bea.com/branding/css/styles.css
#request# GET 
https://www.projects.dev2dev.bea.com/local/images/bullet_.gif
GET /local/images/bullet_.gif
#request# GET https://www.projects.dev2dev.bea.com/favicon.ico
GET /favicon.ico

I realized that after I posted my credentials to the server, line 2 of the 

output, I could simply just do a get on the /servlets/MyStartPage to get 
where I needed. This seems to work. :) Anyways, I tried catching the 
Status 
Code of 302 and redirecting as well but still end up with just a redirect 
page. I probably screwed that up. Based on the output of the Live Headers, 

would you be able to give me some insight as to how you would approach 
such 
a series of POST/GET requests to make my application more stable? Take 
care, 
Jeremy

On 9/9/05, Jeremy Whitlock <jcscoobyrs@gmail.com> wrote:
> 
> Roland,
> Thanks for the help. That was what I had gathered yesterday by reading 
the 
> spec but I wasn't sure how to handle it. I now have a better understand 
and 
> with your suggestion, I think I can get this to work. I'll keep you all 
> posted. Take care, Jeremy
> 
> On 9/9/05, Roland Weber <ROLWEBER@de.ibm.com> wrote:
> > 
> > Hi Jeremy,
> > 
> > > If I turn on post redirects, the code doesn't run.
> > 
> > It's not allowed to run, in compliance with RFC 2616,
> > sections 10.3.2, 10.3.3 and 10.3.8:
> > 
> > <quote>
> > If the 30? status code is received in response to a request other 
> > than GET or HEAD, the user agent MUST NOT automatically redirect the
> > request unless it can be confirmed by the user, since this might
> > change the conditions under which the request was issued.
> > </quote> 
> > 
> > But your application can simply check the response for a
> > 301, 302 or 307 response code, then read the "Location:"
> > response header, and generate a followup request. Either
> > a POST or a GET, as appropriate. Probably a GET. 
> > 
> > hope that helps,
> > Roland
> > 
> > > It errors out. When they
> > > are off, here is the content I get a page from BEA saying that the
> > resource
> > > has moved. The HTML is irrelevant so here is the debugging 
information 
> > 
> > from
> > > the HttpClient logging:
> > >
> > > http://www.rafb.net/paste/results/kGUsCS28.html
> > >
> > > If I didn't log enough or logged the wrong things, let me know. 
Other 
> > than
> > > that...if you see anything I can do differently to get around this
> > hurdle I
> > > would be greatly appreciative. Take care and thanks for your help 
thus
> > far,
> > > Jeremy
> > >
> > > On 9/8/05, Gustavo Hexsel < ghexsel@sagebrushcorp.com> wrote:
> > > >
> > > > I know there is some limitation about POST redirects, which seems 
to
> > be
> > > > the case. But you are in the right path. Have you tried monitoring 

> > which
> > > > intermediate steps happen after authentication (using Mozilla's 
> > tool)?
> > You
> > > > should probably disable followsRedirect, see what comes back, and
> > create
> > > > another POST step that mimicks that. I could take a look, but 
you'll 
> > 
> > have
> > > > to send the relevant parts of the wire log (the headers that are
> > comming
> > > > back just before the "java.lang.IllegalArgumentException: Entity
> > enclosing
> > > > requests cannot be 
> > > > redirected without user intervention").
> > > >
> > > > []s Gus
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Jeremy Whitlock [mailto: jcscoobyrs@gmail.com]
> > > > Sent: September 8, 2005 5:26 PM
> > > > To: HttpClient User Discussion
> > > > Subject: Re: POST Form Session Expired
> > > >
> > > >
> > > > Gustavo,
> > > > I have already tried this before to get yet another error. But 
just 
> > to 
> > 
> > > > make
> > > > sure I am doing what you are saying, here is my updated code:
> > > >
> > > > http://www.rafb.net/paste/results/1g6i0M37.html 
> > > >
> > > > Upon running this, I get the following:
> > > >
> > > > Sep 8, 2005 5:21:44 PM
> > > > org.apache.commons.httpclient.HttpMethodDirectorisRedirectNeeded
> > > > INFO: Redirect requested but followRedirects is disabled 
> > > >
> > > > I cannot do post.setFollowRedirects(true) because it then 
complains
> > about:
> > > >
> > > > java.lang.IllegalArgumentException: Entity enclosing requests 
cannot
> > be
> > > > redirected without user intervention 
> > > > at
> > > >
> > > >
> > 
> > 
org.apache.commons.httpclient.methods.EntityEnclosingMethod.setFollowRedirec
> > > > ts
> > > > (EntityEnclosingMethod.java:221)
> > > > at com.jwhitlock.http.client.HttpClientTutorial.main (
> > > > HttpClientTutorial.java
> > > > :192)
> > > > Exception in thread "main"
> > > >
> > > > I've not found a working solution but I'm sure we can figure this 
> > out.
> > 
> > > > Take 
> > > > care, Jeremy
> > > >
> > > > On 9/8/05, Gustavo Hexsel <ghexsel@sagebrushcorp.com> wrote:
> > > > >
> > > > > About the POST problem, can you post that part of the wire log? 
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Gustavo Hexsel [mailto:ghexsel@sagebrushcorp.com]
> > > > > Sent: September 8, 2005 4:53 PM
> > > > > To: 'HttpClient User Discussion'
> > > > > Subject: RE: POST Form Session Expired
> > > > >
> > > > >
> > > > > Cookies. Reuse the HttpClient instance throughout the whole 
> > operation.
> > > > >
> > > > > -----Original Message-----
> > > > > From: Jeremy Whitlock [mailto:jcscoobyrs@gmail.com]
> > > > > Sent: September 8, 2005 4:48 PM 
> > > > > To: HttpClient-User
> > > > > Subject: POST Form Session Expired
> > > > >
> > > > >
> > > > > Hey all,
> > > > > I am doing a GET on a login form, parsing the form for hidden 
> > input 
> > and
> > > > > then
> > > > >
> > > > > creating a POST with NameValuePair objects corresponding to the
> > hidden
> > > > > input
> > > > >
> > > > > and the two form input fields. I seem to have a minor problem 
with 
> > 
> > my
> > > > > approach as I always get a "Session Expired" from the server I'm
> > logging
> > > > > into. Can someone give me a pseudo flow of how this goes? Here 
is
> > the
> > > > > current code: 
> > > > >
> > > > > http://www.rafb.net/paste/results/mnOMtY87.html
> > > > >
> > > > > Can someone see what I'm doing wrong? I have tried a minor spin 
on 
> > 
> > this
> > > > > where instead of creating an HttpClient for each method I have a
> > global
> > > > > one
> > > > > but then I get a problem with the POST not being able to 
redirect.
> > > > Thanks, 
> > > > > Jeremy
> > > > > --
> > > > > He who listens well, speaks well.
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: 
> > httpclient-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > httpclient-user-help@jakarta.apache.org
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > httpclient-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > httpclient-user-help@jakarta.apache.org
> > > > > 
> > > > >
> > > >
> > > >
> > > > --
> > > > He who listens well, speaks well.
> > > >
> > > > 
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: 
> > httpclient-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > httpclient-user-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > He who listens well, speaks well.
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: 
httpclient-user-help@jakarta.apache.org
> > 
> > 
> 
> 
> -- 
> He who listens well, speaks well. 
> 



-- 
He who listens well, speaks well.



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


Mime
View raw message