Patch for aggregating cookies during redirects

[Alex Rothenberg]

Hi,

I'm not sure how you like to receive patch requests as I couldn't find
a working lighthouse link.

I've created a patch to the party on github
http://github.com/alexrothenberg/httparty/commit/c84c6c968ab8b15c88afbbc410c1e1c7db82a2c2.

The patch does 2 things when a redirect is followed.

1 - It takes the 'set-cookie' header from the redirect response and
sends the cookie along to the next request
2 - It takes the 'set-cookie' header from all the responses and
concatenates them together to return to the caller

I needed to do this as I'm dealing with a site that does form based
authentication where you post your credentials to a url and it then
redirects you to the homepage with a session_id cookie. The homepage
will not let me in unless I do #1 and if I want to make another
request I need #2 to get that cookie in my client code and pass it
along.

Please let me know what you think and what the best way to (hopefully)
get this patch rolled back into the official gem.

Thanks
Alex

[John Nunemaker]

This seems like a pretty specific use case. I don't know that I can
see lots of people needing it, which is what I would like to keep
HTTParty for. I would just make this a separate gem or something
specific for your app.

[Alex Rothenberg]

John,

I am willing to keep my code in my app but I do think what I'm doing
is more general than just my app as the convoluted redirects in the
login are all generated by J2EE (or the WebSphere implementation of
it). I imagine others may want to use HTTParty to connect to existing
J2EE applications so might want to do something similar.

To give you more detail here is the login process of the app I'm
trying to connect to
1 - Users trying to access any page are redirected to an application
specific page http://my.server.com/myapp/login.jsp (this is configured
by the application in the j2ee web.xml)
2 - Users fill out the login form and click submit which posts the
credentials as http://my.server.com/myapp/j_security_check?j_username=my_name&j_password=my_password
3 - J2EE/WebSphere code authenticates and sends a redirect back to
http://my.server.com/myapp (with several session cookies)
4 - The browser requests the home page with the session cookie,
WebSphere authorizes and lets the application show the home page

I'm unable to use HTTParty without my changes to do steps 2-4. I have
put my patch into my app and that is working but I would ask that you
take one more moment to reconsider how specific my request is.

Thanks
Alex

On May 10, 12:54 am, John Nunemaker <nunema...@gmail.com> wrote:
> This seems like a pretty specific use case. I don't know that I can  
> see lots of people needing it, which is what I would like to keep  
> HTTParty for. I would just make this a separate gem or something  
> specific for your app.
>
> On May 8, 2009, at 10:32 AM, Alex Rothenberg wrote:
>
>
>
> > Hi,
>
> > I'm not sure how you like to receive patch requests as I couldn't find
> > a working lighthouse link.
>
> > I've created a patch to the party on github

> >http://github.com/alexrothenberg/httparty/commit/c84c6c968ab8b15c88af...

[John Nunemaker]

It sounds like you would be better served using something like
machanize.
http://mechanize.rubyforge.org/mechanize/

HTTParty is more for API stuff that uses http and tokens for
authentication rather than simulated browser sessions.

[Alex Rothenberg]

John,

Thanks for the pointer. I'll look into Mechanize.

--alex

On May 11, 1:46 pm, John Nunemaker <nunema...@gmail.com> wrote:
> It sounds like you would be better served using something like  

> machanize.http://mechanize.rubyforge.org/mechanize/

>
> HTTParty is more for API stuff that uses http and tokens for  
> authentication rather than simulated browser sessions.
>
> On May 11, 2009, at 10:11 AM, Alex Rothenberg wrote:
>
>
>
> > John,
>
> > I am willing to keep my code in my app but I do think what I'm doing
> > is more general than just my app as the convoluted redirects in the
> > login are all generated by J2EE (or the WebSphere implementation of
> > it).  I imagine others may want to use HTTParty to connect to existing
> > J2EE applications so might want to do something similar.
>
> > To give you more detail here is the login process of the app I'm
> > trying to connect to
> > 1 - Users trying to access any page are redirected to an application

> > specific pagehttp://my.server.com/myapp/login.jsp(this is configured

> > by the application in the j2ee web.xml)
> > 2 - Users fill out the login form and click submit which posts the

> > credentials ashttp://my.server.com/myapp/j_security_check?j_username=my_name&j_pass...

> > 3 - J2EE/WebSphere code authenticates and sends a redirect back to

> >http://my.server.com/myapp(with several session cookies)