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 11:30:01 +1100
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:
>
> 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