Re: Malformed Cookies and WO
Re: Malformed Cookies and WO
- Subject: Re: Malformed Cookies and WO
- From: Peter Vandoros <email@hidden>
- Date: Fri, 11 Feb 2011 13:31:19 +1100
Without analysing the code further, it appears the parser tries all that it can to continue parsing the cookie string and fails when it doesn't have any other option.
I guess you could try re-writing it in completely different way if you wanted a more controllable mechanism.
Regards,
Peter
On 11/02/2011, at 1:16 PM, Dov Rosenberg wrote:
> Is there any way to just skip over the bad cookies and continue on - i.e.
> Like if the malformed cookie is the third out of 5 cookies
>
> Thanks
>
> Dov Rosenberg
>
>
> On 2/10/11 8:35 PM, "Peter Vandoros" <email@hidden> wrote:
>
>> "Debugging" _WOCookieParser, an IllegalStateException is thrown when it
>> encounters a problem. The exception is caught and
>> WOApplication.application().handleMalformedCookieString() is called. in
>> WOApplication.application().handleMalformedCookieString(), the initialisation
>> parameter is checked and then returns the NSDictionary of already parsed
>> cookies (if parameter set to true).
>>
>> This confirms that it does quit processing subsequent cookies on the first
>> error encountered :)
>>
>> Regards,
>>
>> Peter
>>
>> On 11/02/2011, at 12:21 PM, Tom M. Blenko wrote:
>>
>>>
>>> I had the flag running in production on one site for a couple of years (same
>>> situation you mention) with no problems - I don't believe it just quits
>>> parsing on a single error but I don't know. You might want use
>>> WOApplication.handleMalformedCookieString(), which returns cookies
>>> successfully parsed, if you want to check it out further or try to better
>>> recovery yourself.
>>>
>>> Tom
>>>
>>>
>>> On Feb 10, 2011, at 4:30 PM, Peter Vandoros wrote:
>>>
>>>> With the initialisation parameter you mention, I believe the CookieParser
>>>> will stop parsing subsequent cookies once it encounters a malformed one.
>>>> This means that if the malformed cookie happens to be the first one, as sent
>>>> by the user's browser, then you application won't receive any subsequent
>>>> cookies. This will obviously break the WO session handling via cookies.
>>>>
>>>> I'm not sure what to do other than "write" your own _CookieParser :)
>>>>
>>>> Regards,
>>>>
>>>> Peter
>>>>
>>>> On 11/02/2011, at 7:14 AM, Dov Rosenberg wrote:
>>>>
>>>>> We came across a strange issue that took a bit to figure out but thought it
>>>>> would be worthwhile to let everyone else know what happened
>>>>>
>>>>> Problem
>>>>> Some users were having trouble saving a form (WOComponent based)
>>>>> intermittently. Normally these kinds of problems are nearly impossible to
>>>>> figure out unless you get lucky. We got lucky.
>>>>>
>>>>> Root Cause
>>>>> Looking thru the log files we saw a handful of error messages that looked
>>>>> like
>>>>>
>>>>> 410901380 [http-8228-Processor2] WARN er.extensions.appserver.ERXRequest -
>>>>> java.lang.IllegalStateException: Malformed cookie content:
>>>>>
>>>>> The default OOTB behavior of WebObjects is to throw an exception when a
>>>>> malformed cookie is detected in the HTTP Request. This disrupts the normal
>>>>> HTTP request/response loop which played hell with our WOComponent.
>>>>>
>>>>> The malformed cookie was being set by another web site in their domain that
>>>>> was using Google Analytics. Not sure what the problem was with the cookie –
>>>>> saw one that URL encoded 4 times over and another with a null value.
>>>>>
>>>>> Solution
>>>>> Thankfully the WO folks realized that throwing an exception while
>>>>> processing cookies might be a bad thing (default behavior) that they added
>>>>> an initialization parameter to change the default behavior to something
>>>>> more sensible. By setting WOAcceptMalformedCookies=true all cookies will be
>>>>> accepted but the malformed ones will be dropped and not processed. After
>>>>> changing the default behavior our app stopped misbehaving.
>>>>>
>>>>> Not sure if changing the default behavior is a good thing from a security
>>>>> perspective but it did resolve the error for us. Anyone have any thoughts
>>>>> on the impact of this change?
>>>>>
>>>>> Dov Rosenberg
>>>>> InQuira
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> l.com
>>>>>
>>>>> This email sent to email@hidden
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>> tems.com
>>>>
>>>> This email sent to email@hidden
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>> com
>>>
>>> This email sent to email@hidden
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden