Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 75954 invoked from network); 10 Dec 2004 15:00:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 10 Dec 2004 15:00:09 -0000 Received: (qmail 38667 invoked by uid 500); 10 Dec 2004 14:59:00 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 38577 invoked by uid 500); 10 Dec 2004 14:58:59 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 38516 invoked by uid 99); 10 Dec 2004 14:58:59 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from v07274.home.net.pl (HELO v07274.home.net.pl) (212.85.125.162) by apache.org (qpsmtpd/0.28) with SMTP; Fri, 10 Dec 2004 06:58:57 -0800 Received: from sj162.internetdsl.tpnet.pl (HELO ?192.168.1.62?) (lgawron.mobilebox@home@80.55.87.162) by matrix15.home.net.pl with SMTP; 10 Dec 2004 14:58:52 -0000 Message-ID: <41B9B9AE.3010008@mobilebox.pl> Date: Fri, 10 Dec 2004 15:58:54 +0100 From: Leszek Gawron User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Possible security problem with flowscript References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Johan Stuyts wrote: > Hi, > > Sorry about reacting to this thread after one month of inactivity, but we recently switched to a Cocoon version which includes this fix. I have tried refactoring our application, but it was more work than I expected. > > Having an option to turn this behaviour on or off would really make things easier for me. Our application can run as it is and from the warnings in the log I can determine what should be changed. Using these warnings I can gradually make our application compliant with sitemap-bound continuations. > > I propose to change the current code in ContinuationsManagerImpl to this code. As you can see the warnings will always be added to the log as an incentive to make changes to code which still uses shared continuations: > public WebContinuation lookupWebContinuation(String id, String interpreterId) { > WebContinuation kont = (WebContinuation) idToWebCont.get(id); > if ( kont != null ) { > boolean interpreterMatches = kont.interpreterMatches(interpreterId); > if (!interpreterMatches && getLogger().isWarnEnabled()) { > getLogger().warn("WK: Continuation (" + kont.getId() > + ") lookup for wrong interpreter. Bound to: " > + kont.getInterpreterId() + ", looked up for: " > + interpreterId); > } > >>>>> return interpreterMatches || allowBackwardCompatibleContinuationSharing ? kont : null; > > } > return null; > } > > 'allowBackwardCompatibleContinuationSharing' will be a configuration option which defaults to 'false'. > > If nobody objects I will make the changes, create patches and add a new bug for this. > > Johan Stuyts Johan, Please describe your usecase when you were resuming continuations in different sitemap. What did you try to achieve by this? -- Leszek Gawron lgawron@mobilebox.pl Project Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65