[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httpclient-users
Subject:    Re: Secure cookie not being set [was: Two-Way SSL Problem]
From:       "Tim Williams" <williamstw () gmail ! com>
Date:       2009-01-12 15:33:42
Message-ID: 499888440901120733p4c14bd9an8422c332b68edf7 () mail ! gmail ! com
[Download RAW message or body]

On Mon, Jan 12, 2009 at 9:33 AM, Tim Williams <williamstw@gmail.com> wrote:
> On Mon, Jan 12, 2009 at 9:05 AM, Tim Williams <williamstw@gmail.com> wrote:
>> On Mon, Jan 12, 2009 at 8:52 AM, Oleg Kalnichevski <olegk@apache.org> wrote:
>>> On Mon, 2009-01-12 at 08:28 -0500, Tim Williams wrote:
>>>> On Thu, Jan 8, 2009 at 3:03 PM, Tim Williams <williamstw@gmail.com> wrote:
>>>> > On Thu, Jan 8, 2009 at 2:28 PM, Tim Williams <williamstw@gmail.com> wrote:
>>>> >> On Thu, Jan 8, 2009 at 2:09 PM, Oleg Kalnichevski <olegk@apache.org> wrote:
>>>> >>> Tim Williams wrote:
>>>> >>>>
>>>> >>>> I'm using the MultiThreadedConnectionManager with HttpClient and 2-way
>>>> >>>> ssl similar to the example[1] and having problems.  The very first
>>>> >>>> request goes through and returns HTTP 200 Ok.  All subsequent requests
>>>> >>>> return HTTP 401.  This happens when I run this inside a webapp
>>>> >>>> deployed in either glassfish or tomcat.  However, if I take the same
>>>> >>>> code and run from within a simple driver "main" program, all calls to
>>>> >>>> that same server succeed with no problems.  Oddly enough, this only
>>>> >>>> happens when communicating with one particular Weblogic service -
>>>> >>>> other servers allow multiple calls with the same fetcher code just
>>>> >>>> fine.  Anyone have an idea what would make the first request go
>>>> >>>> through go through properly but not subsequent ones?
>>>> >>>>
>>>> >>>
>>>> >>> There is no way of telling without more details. Please post a wire log of
>>>> >>> the HTTP session to this list
>>>> >>>
>>>> >>> http://hc.apache.org/httpclient-3.x/logging.html
>>>> >>>
>>>> >>> Oleg
>>>> >>
>>>> >> Unfortunately, I'm unable to post logging data.  I have narrowed it
>>>> >> down to a "cookie" problem of some sort.  I've found that if I
>>>> >> manually take the "Set-Cookie" header from the initial request, store
>>>> >> it, then manually populate it on subsequent requests, all is well.  I
>>>> >> had that idea from this site[1] but I'm not sure whether the
>>>> >> configuration on the server-side (Weblogic) is just wrong or my
>>>> >> HttpClient configuration is wrong by not sending back both cookies on
>>>> >> subsequent requests.
>>>> >> Thanks,
>>>> >> --tim
>>>> >
>>>> > I've run the wire logging and it does appear that two Set-Cookies are
>>>> > coming in, one with JSESSIONID= and the other with
>>>> > _WL_AUTH_JSESSIONID=.  On subsequent requests, only the first,
>>>> > JSESSIONID, is on the outbound request.  Any ideas?
>>>>
>>>> The _WL_AUTH_JSESSIONID is a 'secure' cookie and it is the one not
>>>> being sent. Weblogic uses both a regular cookie and secure cookie to
>>>> apparently allow you to seamlessly transition across http and https
>>>> sessions[1] which seems valid. I've tried sending as a
>>>> SINGLE_COOKIE_HEADER as well with no success.  I'm using v3.0.1 and
>>>> RFC2109 btw.  Any ideas for what to look at?
>>>> Thanks,
>>>> --tim
>>>>
>>>
>>> You are not using a custom SSL socket factory, are you? If so, make sure
>>> it implements SecureProtocolSocketFactory interface.
>>>
>>> Oleg
>>
>> No, I'm not.  I also just tried explicitly registering the
>> SSLProtocolSocketFactory in my code - though I reckon its unnecessary
>> - but that doesn't help.  I also found this thread[1] which looks
>> similar.  I don't like the suggested hack though (manually removing
>> the secure flag from the cookie).  Any other ideas?
>
> Actually, explicitly registering the SSLProtocolSocketFactory for
> "https" *does* help.  This is odd because it looks like exactly what
> the lazyRegisterProtocol method is already doing.

In hindsight, with a little more knowledge of how the cookie match and
isSecure works, the first troubleshooting step should have been:
log.debug("Protocol instance: " +
Protocol.getProtocol("https").getSocketFactory().getClass().getCanonicalName());

This would help identify a registered socketfactory on the classpath
that didn't implement SecureProtocolSocketFactory :(  Thanks Oleg for
your tips...

--tim

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

[prev in list] [next in list] [prev in thread] [next in thread]