You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by lg...@apache.org on 2004/12/08 12:47:13 UTC
svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Author: lgawron
Date: Wed Dec 8 03:47:12 2004
New Revision: 111262
URL: http://svn.apache.org/viewcvs?view=rev&rev=111262
Log:
implement 2 modes of work for continuations manager:
- standard, as it was up till now
- secure in which continuations are bound to session. Only the session that created a continuation can invoke it.
All continuations bound to session are invalidated when the session ifself gets invalidated.
This mode is for those users who build web applications protected with authentification.
Modified:
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java
cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/WebContinuation.java
cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf
Modified: cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java
Url: http://svn.apache.org/viewcvs/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java?view=diff&rev=111262&p1=cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java&r1=111261&p2=cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java&r2=111262
==============================================================================
--- cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java (original)
+++ cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java Wed Dec 8 03:47:12 2004
@@ -18,12 +18,19 @@
import org.apache.avalon.framework.component.Component;
import org.apache.avalon.framework.configuration.Configurable;
import org.apache.avalon.framework.configuration.Configuration;
+import org.apache.avalon.framework.context.Context;
+import org.apache.avalon.framework.context.ContextException;
+import org.apache.avalon.framework.context.Contextualizable;
import org.apache.avalon.framework.logger.AbstractLogEnabled;
import org.apache.avalon.framework.service.ServiceException;
import org.apache.avalon.framework.service.ServiceManager;
import org.apache.avalon.framework.service.Serviceable;
import org.apache.avalon.framework.thread.ThreadSafe;
+import org.apache.cocoon.components.ContextHelper;
import org.apache.cocoon.components.thread.RunnableManager;
+import org.apache.cocoon.environment.ObjectModelHelper;
+import org.apache.cocoon.environment.Request;
+import org.apache.cocoon.environment.Session;
import org.apache.excalibur.instrument.CounterInstrument;
import org.apache.excalibur.instrument.Instrument;
@@ -41,11 +48,26 @@
import java.util.SortedSet;
import java.util.TreeSet;
+import javax.servlet.http.HttpSessionBindingEvent;
+import javax.servlet.http.HttpSessionBindingListener;
+
/**
- * The default implementation of {@link ContinuationsManager}.
- *
- * @author <a href="mailto:ovidiu@cup.hp.com">Ovidiu Predescu</a>
- * @author <a href="mailto:Michael.Melhem@managesoft.com">Michael Melhem</a>
+ * The default implementation of {@link ContinuationsManager}. < <br/>There are
+ * two modes of work: <br/>
+ * <ul>
+ * <li><b>standard mode </b>- continuations are stored in single holder. No
+ * security is applied to continuation lookup. Anyone can invoke a continuation
+ * only knowing the ID. Set "session-bound-continuations" configuration option
+ * to false to activate this mode.</li>
+ * <li><b>secure mode </b>- each session has it's own continuations holder. A
+ * continuation is only valid for the same session it was created for. Session
+ * invalidation causes all bound continuations to be invalidated as well. Use
+ * this setting for web applications. Set "session-bound-continuations"
+ * configuration option to true to activate this mode.</li>
+ * </ul>
+ *
+ * @author <a href="mailto:ovidiu@cup.hp.com">Ovidiu Predescu </a>
+ * @author <a href="mailto:Michael.Melhem@managesoft.com">Michael Melhem </a>
* @since March 19, 2002
* @see ContinuationsManager
* @version CVS $Id$
@@ -53,7 +75,7 @@
public class ContinuationsManagerImpl
extends AbstractLogEnabled
implements ContinuationsManager, Component, Configurable,
- ThreadSafe, Instrumentable, Serviceable {
+ ThreadSafe, Instrumentable, Serviceable, Contextualizable {
static final int CONTINUATION_ID_LENGTH = 20;
static final String EXPIRE_CONTINUATIONS = "expire-continuations";
@@ -78,11 +100,11 @@
protected Set forest = Collections.synchronizedSet(new HashSet());
/**
- * Association between <code>WebContinuation</code> IDs and the
- * corresponding <code>WebContinuation</code> objects.
+ * Main continuations holder. Used unless continuations are stored in user
+ * session.
*/
- protected Map idToWebCont = Collections.synchronizedMap(new HashMap());
-
+ protected WebContinuationsHolder continuationsHolder;
+
/**
* Sorted set of <code>WebContinuation</code> instances, based on
* their expiration time. This is used by the background thread to
@@ -92,13 +114,16 @@
private String instrumentableName;
private ValueInstrument continuationsCount;
+ private int continuationsCounter;
private ValueInstrument forestSize;
private ValueInstrument expirationsSize;
private CounterInstrument continuationsCreated;
private CounterInstrument continuationsInvalidated;
private boolean isContinuationSharingBugCompatible;
+ private boolean bindContinuationsToSession;
private ServiceManager serviceManager;
+ private Context context;
public ContinuationsManagerImpl() throws Exception {
try {
@@ -111,6 +136,7 @@
bytes = new byte[CONTINUATION_ID_LENGTH];
continuationsCount = new ValueInstrument("count");
+ continuationsCounter = 0;
forestSize = new ValueInstrument("forest-size");
expirationsSize = new ValueInstrument("expirations-size");
continuationsCreated = new CounterInstrument("creates");
@@ -124,7 +150,10 @@
public void configure(Configuration config) {
this.defaultTimeToLive = config.getAttributeAsInteger("time-to-live", (3600 * 1000));
this.isContinuationSharingBugCompatible = config.getAttributeAsBoolean("continuation-sharing-bug-compatible", false);
-
+ this.bindContinuationsToSession = config.getAttributeAsBoolean( "session-bound-continuations", false );
+ if (!this.bindContinuationsToSession)
+ this.continuationsHolder = new WebContinuationsHolder();
+
final Configuration expireConf = config.getChild("expirations-check");
final long initialDelay = expireConf.getChild("offset", true).getValueAsLong(180000);
final long interval = expireConf.getChild("period", true).getValueAsLong(180000);
@@ -201,7 +230,11 @@
public WebContinuation lookupWebContinuation(String id, String interpreterId) {
// REVISIT: Is the following check needed to avoid threading issues:
// return wk only if !(wk.hasExpired) ?
- WebContinuation kont = (WebContinuation) idToWebCont.get(id);
+ WebContinuationsHolder continuationsHolder = lookupWebContinuationsHolder(false);
+ if (continuationsHolder == null)
+ return null;
+
+ WebContinuation kont = (WebContinuation) continuationsHolder.get(id);
if ( kont != null ) {
boolean interpreterMatches = kont.interpreterMatches(interpreterId);
if (!interpreterMatches && getLogger().isWarnEnabled()) {
@@ -232,14 +265,12 @@
* @return the generated <code>WebContinuation</code> with unique identifier
*/
private WebContinuation generateContinuation(Object kont,
- WebContinuation parent,
- int ttl,
- String interpreterId,
- ContinuationsDisposer disposer) {
+ WebContinuation parent, int ttl, String interpreterId,
+ ContinuationsDisposer disposer) {
char[] result = new char[bytes.length * 2];
WebContinuation wk = null;
-
+ WebContinuationsHolder continuationsHolder = lookupWebContinuationsHolder(true);
while (true) {
random.nextBytes(bytes);
@@ -250,11 +281,20 @@
}
final String id = new String(result);
- synchronized (idToWebCont) {
- if (!idToWebCont.containsKey(id)) {
- wk = new WebContinuation(id, kont, parent, ttl, interpreterId, disposer);
- idToWebCont.put(id, wk);
- continuationsCount.setValue(idToWebCont.size());
+ synchronized (continuationsHolder) {
+ if (!continuationsHolder.contains(id)) {
+ if (this.bindContinuationsToSession)
+ wk = new HolderAwareWebContinuation(id, kont, parent,
+ ttl, interpreterId, disposer,
+ continuationsHolder);
+ else
+ wk = new WebContinuation(id, kont, parent, ttl,
+ interpreterId, disposer);
+ continuationsHolder.addContinuation(wk);
+ synchronized (continuationsCount) {
+ continuationsCounter++;
+ continuationsCount.setValue(continuationsCounter);
+ }
break;
}
}
@@ -265,15 +305,20 @@
}
public void invalidateWebContinuation(WebContinuation wk) {
+ WebContinuationsHolder continuationsHolder = lookupWebContinuationsHolder(false);
+ if (!continuationsHolder.contains(wk)) {
+ //TODO this looks like a security breach - should we throw?
+ return;
+ }
_detach(wk);
- _invalidate(wk);
+ _invalidate(continuationsHolder, wk);
}
- private void _invalidate(WebContinuation wk) {
+ private void _invalidate(WebContinuationsHolder continuationsHolder, WebContinuation wk) {
if (getLogger().isDebugEnabled()) {
getLogger().debug("WK: Manual expire of continuation " + wk.getId());
}
- disposeContinuation(wk);
+ disposeContinuation(continuationsHolder, wk);
expirations.remove(wk);
expirationsSize.setValue(expirations.size());
@@ -281,7 +326,7 @@
List children = wk.getChildren();
int size = children.size();
for (int i = 0; i < size; i++) {
- _invalidate((WebContinuation) children.get(i));
+ _invalidate(continuationsHolder, (WebContinuation) children.get(i));
}
}
@@ -289,6 +334,7 @@
* Detach this continuation from parent. This method removes
* continuation from {@link #forest} set, or, if it has parent,
* from parent's children collection.
+ * @param continuationsHolder
* @param wk Continuation to detach from parent.
*/
private void _detach(WebContinuation wk) {
@@ -296,21 +342,23 @@
if (parent == null) {
forest.remove(wk);
forestSize.setValue(forest.size());
- } else {
- List parentKids = parent.getChildren();
- parentKids.remove(wk);
- }
+ } else
+ wk.detachFromParent();
}
/**
* Makes the continuation inaccessible for lookup, and triggers possible needed
* cleanup code through the ContinuationsDisposer interface.
+ * @param continuationsHolder
*
* @param wk the continuation to dispose.
*/
- private void disposeContinuation(WebContinuation wk) {
- idToWebCont.remove(wk.getId());
- continuationsCount.setValue(idToWebCont.size());
+ private void disposeContinuation(WebContinuationsHolder continuationsHolder, WebContinuation wk) {
+ continuationsHolder.removeContinuation(wk);
+ synchronized( continuationsCount ) {
+ continuationsCounter--;
+ continuationsCount.setValue(continuationsCounter);
+ }
wk.dispose();
continuationsInvalidated.increment();
}
@@ -319,16 +367,18 @@
* Removes an expired leaf <code>WebContinuation</code> node
* from its continuation tree, and recursively removes its
* parent(s) if it they have expired and have no (other) children.
+ * @param continuationsHolder
*
* @param wk <code>WebContinuation</code> node
*/
- private void removeContinuation(WebContinuation wk) {
+ private void removeContinuation(WebContinuationsHolder continuationsHolder,
+ WebContinuation wk) {
if (wk.getChildren().size() != 0) {
return;
}
// remove access to this contination
- disposeContinuation(wk);
+ disposeContinuation(continuationsHolder, wk);
_detach(wk);
if (getLogger().isDebugEnabled()) {
@@ -338,7 +388,8 @@
// now check if parent needs to be removed.
WebContinuation parent = wk.getParentContinuation();
if (null != parent && parent.hasExpired()) {
- removeContinuation(parent);
+ //parent must have the same continuations holder, lookup not needed
+ removeContinuation(continuationsHolder, parent);
}
}
@@ -399,7 +450,12 @@
Iterator i = expirations.iterator();
while (i.hasNext() && ((wk = (WebContinuation) i.next()).hasExpired())) {
i.remove();
- removeContinuation(wk);
+ WebContinuationsHolder continuationsHolder = null;
+ if ( wk instanceof HolderAwareWebContinuation )
+ continuationsHolder = ((HolderAwareWebContinuation) wk).getContinuationsHolder();
+ else
+ continuationsHolder = this.continuationsHolder;
+ removeContinuation(continuationsHolder, wk);
count++;
}
expirationsSize.setValue(expirations.size());
@@ -414,5 +470,130 @@
displayExpireSet();
*/
}
+ }
+
+ /**
+ * Method used by WebContinuationsHolder to notify the continuations manager
+ * about session invalidation. Invalidates all continuations held by passed
+ * continuationsHolder.
+ */
+ private void invalidateContinuations(
+ WebContinuationsHolder continuationsHolder) {
+ Set continuationIds = continuationsHolder.getContinuationIds();
+ Iterator idsIter = continuationIds.iterator();
+ while (idsIter.hasNext()) {
+ WebContinuation wk = continuationsHolder.get((String) idsIter.next());
+ if (wk != null) {
+ _detach(wk);
+ _invalidate(continuationsHolder, wk);
+ }
+ }
+ }
+
+ /**
+ * Lookup a proper web continuations holder.
+ * @param createNew
+ * should the manager create a continuations holder in session
+ * when none found?
+ */
+ public WebContinuationsHolder lookupWebContinuationsHolder(boolean createNew) {
+ //there is only one holder if continuations are not bound to session
+ if (!this.bindContinuationsToSession)
+ return this.continuationsHolder;
+
+ //if continuations bound to session lookup a proper holder in the session
+ Map objectModel = ContextHelper.getObjectModel(this.context);
+ Request request = ObjectModelHelper.getRequest(objectModel);
+
+ if (!createNew && request.getSession(false) == null)
+ return null;
+
+ Session session = request.getSession(true);
+ WebContinuationsHolder holder =
+ (WebContinuationsHolder) session.getAttribute(
+ WebContinuationsHolder.CONTINUATIONS_HOLDER);
+ if (!createNew)
+ return holder;
+
+ if (holder != null)
+ return holder;
+
+ holder = new WebContinuationsHolder();
+ session.setAttribute(WebContinuationsHolder.CONTINUATIONS_HOLDER,
+ holder);
+ return holder;
+ }
+
+ /**
+ * A holder for WebContinuations. When bound to session notifies the
+ * continuations manager of session invalidation.
+ */
+ private class WebContinuationsHolder implements HttpSessionBindingListener {
+ private final static String CONTINUATIONS_HOLDER =
+ "o.a.c.c.f.SCMI.WebContinuationsHolder";
+
+ private Map holder = Collections.synchronizedMap(new HashMap());
+
+ public WebContinuation get(Object id) {
+ return (WebContinuation) this.holder.get(id);
+ }
+
+ public void addContinuation(WebContinuation wk) {
+ this.holder.put(wk.getId(), wk);
+ }
+
+ public void removeContinuation(WebContinuation wk) {
+ this.holder.remove(wk.getId());
+ }
+
+ public Set getContinuationIds() {
+ return holder.keySet();
+ }
+
+ public boolean contains(String continuationId) {
+ return this.holder.containsKey(continuationId);
+ }
+
+ public boolean contains(WebContinuation wk) {
+ return contains(wk.getId());
+ }
+
+ public void valueBound(HttpSessionBindingEvent event) {
+ }
+
+ public void valueUnbound(HttpSessionBindingEvent event) {
+ invalidateContinuations(this);
+ }
+ }
+
+ /**
+ * WebContinuation extension that holds also the information about the
+ * holder. This information is needed to cleanup a proper holder after
+ * continuation's expiration time.
+ */
+ private class HolderAwareWebContinuation extends WebContinuation {
+ private WebContinuationsHolder continuationsHolder;
+
+ public HolderAwareWebContinuation(String id, Object continuation,
+ WebContinuation parentContinuation, int timeToLive,
+ String interpreterId, ContinuationsDisposer disposer,
+ WebContinuationsHolder continuationsHolder) {
+ super(id, continuation, parentContinuation, timeToLive,
+ interpreterId, disposer);
+ this.continuationsHolder = continuationsHolder;
+ }
+
+ public WebContinuationsHolder getContinuationsHolder() {
+ return continuationsHolder;
+ }
+
+ //retain comparation logic from parent
+ public int compareTo(Object other) {
+ return super.compareTo(other);
+ }
+ }
+
+ public void contextualize(Context context) throws ContextException {
+ this.context = context;
}
}
Modified: cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/WebContinuation.java
Url: http://svn.apache.org/viewcvs/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/WebContinuation.java?view=diff&rev=111262&p1=cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/WebContinuation.java&r1=111261&p2=cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/WebContinuation.java&r2=111262
==============================================================================
--- cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/WebContinuation.java (original)
+++ cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/WebContinuation.java Wed Dec 8 03:47:12 2004
@@ -386,4 +386,9 @@
public boolean interpreterMatches( String interpreterId ) {
return StringUtils.equals( this.interpreterId, interpreterId );
}
+
+ public void detachFromParent() {
+ if (getParentContinuation() != null)
+ getParentContinuation().getChildren().remove(this);
+ }
}
Modified: cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf
Url: http://svn.apache.org/viewcvs/cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf?view=diff&rev=111262&p1=cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf&r1=111261&p2=cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf&r2=111262
==============================================================================
--- cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf (original)
+++ cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf Wed Dec 8 03:47:12 2004
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright 1999-2004 The Apache Software Foundation
@@ -119,7 +119,9 @@
| expiring continuations. Currently only the "periodic" type is
| supported.
+-->
- <continuations-manager logger="flow.manager" time-to-live="3600000">
+ <continuations-manager logger="flow.manager" time-to-live="3600000"
+ session-bound-continuations="false"
+ continuation-sharing-bug-compatible="false">
<expirations-check type="periodic">
<offset>180000</offset>
<period>180000</period>
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src:
java/org/apache/cocoon/components/flow webapp/WEB-INF
Posted by Antonio Gallardo <ag...@agssa.net>.
On Jue, 9 de Diciembre de 2004, 2:21, Leszek Gawron dijo:
> By the way: it is a little bit different on win32. Some tools detect utf
> encoding by checking for BOM. If there is none - ANSI encoding is assumed.
....then switch to Linux! ;-)
Best Regards,
Antonio Gallardo
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src:
java/org/apache/cocoon/components/flow webapp/WEB-INF
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Bertrand Delacretaz wrote:
> Le 9 déc. 04, à 09:49, Leszek Gawron a écrit :
>
>> ... Because Microsoft did it, and there is so much Notepad data out
>> there, the UTF-8 BOM became a de facto standard and then a de jure
>> standard. (Although the BOM is optional.)..
>
>
> hmm...not sure if notepad is the kind of reference that we want to use
> here ;-)
>
> Anyway, I think most or all our XML files are UTF-8 with no BOM, so it's
> probably not a good idea to change.
It is not only the problem of notepad. At least 2 tools I use (UltraEdit
and Araxis Merge) follow the same logic.
--
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
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 9 déc. 04, à 09:49, Leszek Gawron a écrit :
> ... Because Microsoft did it, and there is so much Notepad data out
> there, the UTF-8 BOM became a de facto standard and then a de jure
> standard. (Although the BOM is optional.)..
hmm...not sure if notepad is the kind of reference that we want to use
here ;-)
Anyway, I think most or all our XML files are UTF-8 with no BOM, so
it's probably not a good idea to change.
-Bertrand
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src:
java/org/apache/cocoon/components/flow webapp/WEB-INF
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Vadim Gritsenko wrote:
> Antonio Gallardo wrote:
>
>> On Jue, 9 de Diciembre de 2004, 2:49, Leszek Gawron dijo:
>>
>>> Bertrand Delacretaz wrote:
>>>
>>>> Le 9 déc. 04, à 09:21, Leszek Gawron a écrit :
>>>>
>>>>> ...By the way: it is a little bit different on win32. Some tools
>>>>> detect utf encoding by checking for BOM. If there is none - ANSI
>>>>> encoding is assumed...
>>>>
>>>>
>>>> AFAIU this is ok for 16-bit based encodings, not for UTF-8.
>>>>
>>> http://www.xencraft.com/resources/unicodebom.html
>
> ...
>
>>>
>>> M$ again.
>>
>>
>> This is the standard:
>>
>> http://www.zvon.org/tmRFC/RFC3023/Output/chapter8.html#sub1 :-D
>
>
> No, it's not. The standard is:
> http://www.w3c.org/TR/2004/REC-xml11-20040204/#NT-XMLDecl
>
> XML *must* start with '<?xml'. So no MS junk of any kind is allowed.
> Please don't use notepad - vim and far both have syntax highlight and do
> not write boms of any kind :)
I am not using notepad :). Apparently even sophisticated win32 text
editors (like my favourive UltraEdit) support UTF-8 BOMs.
--
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
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src:
java/org/apache/cocoon/components/flow webapp/WEB-INF
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Antonio Gallardo wrote:
> On Jue, 9 de Diciembre de 2004, 2:49, Leszek Gawron dijo:
>
>>Bertrand Delacretaz wrote:
>>
>>>Le 9 déc. 04, à 09:21, Leszek Gawron a écrit :
>>>
>>>>...By the way: it is a little bit different on win32. Some tools
>>>>detect utf encoding by checking for BOM. If there is none - ANSI
>>>>encoding is assumed...
>>>
>>>AFAIU this is ok for 16-bit based encodings, not for UTF-8.
>>>
>>http://www.xencraft.com/resources/unicodebom.html
...
>>
>>M$ again.
>
> This is the standard:
>
> http://www.zvon.org/tmRFC/RFC3023/Output/chapter8.html#sub1 :-D
No, it's not. The standard is:
http://www.w3c.org/TR/2004/REC-xml11-20040204/#NT-XMLDecl
XML *must* start with '<?xml'. So no MS junk of any kind is allowed. Please
don't use notepad - vim and far both have syntax highlight and do not write boms
of any kind :)
Vadim
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src:
java/org/apache/cocoon/components/flow webapp/WEB-INF
Posted by Antonio Gallardo <ag...@agssa.net>.
On Jue, 9 de Diciembre de 2004, 2:49, Leszek Gawron dijo:
> Bertrand Delacretaz wrote:
>> Le 9 déc. 04, à 09:21, Leszek Gawron a écrit :
>>
>>> ...By the way: it is a little bit different on win32. Some tools
>>> detect utf encoding by checking for BOM. If there is none - ANSI
>>> encoding is assumed...
>>
>>
>> AFAIU this is ok for 16-bit based encodings, not for UTF-8.
>>
>> -Bertrand
> http://www.xencraft.com/resources/unicodebom.html
> <quote>
> Even though UTF-8 does not need a BOM to indicate endianness, Microsoft
> Notepad began prepending a BOM to its UTF-8 text files. Actually, it is
> a conversion of U+FEFF to an encoding as UTF-8 serialized bytes: EF BB
> BF (or in 4GL: CHR(15711167)). There is some value in the BOM being used
> as a file signature, indicating the plain text file is encoded as
> Unicode UTF-8, as opposed to some other code page. That particular
> 3-byte sequence is unlikely to represent data in any other code page,
> given the text is supposed to be human readable in some language.
> However, there is some small possibility that it represents some string
> in some code page... Because Microsoft did it, and there is so much
> Notepad data out there, the UTF-8 BOM became a de facto standard and
> then a de jure standard. (Although the BOM is optional.)
> </quote>
>
> M$ again.
This is the standard:
http://www.zvon.org/tmRFC/RFC3023/Output/chapter8.html#sub1 :-D
Best Regards,
Antonio Gallardo.
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src:
java/org/apache/cocoon/components/flow webapp/WEB-INF
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Bertrand Delacretaz wrote:
> Le 9 déc. 04, à 09:21, Leszek Gawron a écrit :
>
>> ...By the way: it is a little bit different on win32. Some tools
>> detect utf encoding by checking for BOM. If there is none - ANSI
>> encoding is assumed...
>
>
> AFAIU this is ok for 16-bit based encodings, not for UTF-8.
>
> -Bertrand
http://www.xencraft.com/resources/unicodebom.html
<quote>
Even though UTF-8 does not need a BOM to indicate endianness, Microsoft
Notepad began prepending a BOM to its UTF-8 text files. Actually, it is
a conversion of U+FEFF to an encoding as UTF-8 serialized bytes: EF BB
BF (or in 4GL: CHR(15711167)). There is some value in the BOM being used
as a file signature, indicating the plain text file is encoded as
Unicode UTF-8, as opposed to some other code page. That particular
3-byte sequence is unlikely to represent data in any other code page,
given the text is supposed to be human readable in some language.
However, there is some small possibility that it represents some string
in some code page... Because Microsoft did it, and there is so much
Notepad data out there, the UTF-8 BOM became a de facto standard and
then a de jure standard. (Although the BOM is optional.)
</quote>
M$ again.
--
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
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 9 déc. 04, à 09:21, Leszek Gawron a écrit :
> ...By the way: it is a little bit different on win32. Some tools
> detect utf encoding by checking for BOM. If there is none - ANSI
> encoding is assumed...
AFAIU this is ok for 16-bit based encodings, not for UTF-8.
-Bertrand
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src:
java/org/apache/cocoon/components/flow webapp/WEB-INF
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Bertrand Delacretaz wrote:
> Le 9 déc. 04, à 01:03, Leszek Gawron a écrit :
>
>>>> ...
>>>> +<?xml version="1.0" encoding="UTF-8"?>
>>>
>>> ...
>>
>> This is BOM (byte ordering mark). It is being written by some of xml
>> editors to the beginning of the multibyte encoded (i.e. utf-8) xml
>> file. The file I commited is a valid xml. Check in any xml
>> editor/browser...
>
>
> BOM has no meaning for UTF-8, see
> http://www.unicode.org/unicode/faq/utf_bom.html#BOM
>
> It is certainly better *not* to use it, to avoid any confusion. On
> unixish OSes, many tools check the first four bytes of a file and expect
> them to be <?xm
>
> -Bertrand
OK. No problem.
By the way: it is a little bit different on win32. Some tools detect utf
encoding by checking for BOM. If there is none - ANSI encoding is assumed.
--
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
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 9 déc. 04, à 01:03, Leszek Gawron a écrit :
>>> ...
>>> +<?xml version="1.0" encoding="UTF-8"?>
>> ...
> This is BOM (byte ordering mark). It is being written by some of xml
> editors to the beginning of the multibyte encoded (i.e. utf-8) xml
> file. The file I commited is a valid xml. Check in any xml
> editor/browser...
BOM has no meaning for UTF-8, see
http://www.unicode.org/unicode/faq/utf_bom.html#BOM
It is certainly better *not* to use it, to avoid any confusion. On
unixish OSes, many tools check the first four bytes of a file and
expect them to be <?xm
-Bertrand
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src:
java/org/apache/cocoon/components/flow webapp/WEB-INF
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 8 de Diciembre de 2004, 18:03, Leszek Gawron dijo:
> Antonio Gallardo wrote:
>> On Mie, 8 de Diciembre de 2004, 5:47, lgawron@apache.org dijo:
>>
>>>Author: lgawron
>>>Date: Wed Dec 8 03:47:12 2004
>>>New Revision: 111262
>>>
>>>URL: http://svn.apache.org/viewcvs?view=rev&rev=111262
>>
>>
>> ...
>>
>>> cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf
>>>---
>>>cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf (original)
>>>+++ cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf Wed Dec
>>>8 03:47:12 2004
>>>@@ -1,4 +1,4 @@
>>>-<?xml version="1.0" encoding="UTF-8"?>
>>>+<?xml version="1.0" encoding="UTF-8"?>
>>
>>
>> ^^^^^
>> |||||
>>
>> What is that? Please, be carefull next time. :-D
>>
>> Best Regards,
>>
>> Antonio Gallardo.
>>
> This is BOM (byte ordering mark). It is being written by some of xml
> editors to the beginning of the multibyte encoded (i.e. utf-8) xml file.
> The file I commited is a valid xml. Check in any xml editor/browser.
>
> The question is do we allow BOMs in xml files? If not I will have to
> look for a way to disable the feature for cocoon files.
AFAIK, BOMs are not allowed in the repository. But if you think we need
that, we can start a vote. I was reading:
http://www.zvon.org/tmRFC/RFC3023/Output/chapter8.html#sub1
WDYT?
Best Regards,
Antonio Gallardo
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src:
java/org/apache/cocoon/components/flow webapp/WEB-INF
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Antonio Gallardo wrote:
> On Mie, 8 de Diciembre de 2004, 5:47, lgawron@apache.org dijo:
>
>>Author: lgawron
>>Date: Wed Dec 8 03:47:12 2004
>>New Revision: 111262
>>
>>URL: http://svn.apache.org/viewcvs?view=rev&rev=111262
>
>
> ...
>
>> cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf
>>---
>>cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf (original)
>>+++ cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf Wed Dec
>>8 03:47:12 2004
>>@@ -1,4 +1,4 @@
>>-<?xml version="1.0" encoding="UTF-8"?>
>>+<?xml version="1.0" encoding="UTF-8"?>
>
>
> ^^^^^
> |||||
>
> What is that? Please, be carefull next time. :-D
>
> Best Regards,
>
> Antonio Gallardo.
>
This is BOM (byte ordering mark). It is being written by some of xml
editors to the beginning of the multibyte encoded (i.e. utf-8) xml file.
The file I commited is a valid xml. Check in any xml editor/browser.
The question is do we allow BOMs in xml files? If not I will have to
look for a way to disable the feature for cocoon files.
--
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
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src:
java/org/apache/cocoon/components/flow webapp/WEB-INF
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 8 de Diciembre de 2004, 5:47, lgawron@apache.org dijo:
> Author: lgawron
> Date: Wed Dec 8 03:47:12 2004
> New Revision: 111262
>
> URL: http://svn.apache.org/viewcvs?view=rev&rev=111262
...
> cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf
> ---
> cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf (original)
> +++ cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf Wed Dec
> 8 03:47:12 2004
> @@ -1,4 +1,4 @@
> -<?xml version="1.0" encoding="UTF-8"?>
> +<?xml version="1.0" encoding="UTF-8"?>
^^^^^
|||||
What is that? Please, be carefull next time. :-D
Best Regards,
Antonio Gallardo.
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow
webapp/WEB-INF
Posted by Stefano Mazzocchi <st...@apache.org>.
Leszek Gawron wrote:
> about 2nd: YAGNI (thanks Stefano for new cool phrase :))
I guess it was Sylvain that introduced me to it, so thank him :-)
--
Stefano.
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow
webapp/WEB-INF
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leszek Gawron wrote:
> Vadim Gritsenko wrote:
>
>> Leszek Gawron wrote:
>>
>>>
>>> Previously we have discussed about three continuations manager work
>>> modes:
>>>
>>> - standard (current functionality)
>>> - continuations invalidated along with session, still the continuation
>>> is reachable from other sessions (or no session at all)
>>> - fully isolated. only the session that created the continuation can
>>> access it.
>>>
>>> Thing is after a while I still do not see a use case for a second
>>> case where continuations would be invalidated with user session but
>>> still accessibe for everyone (of course before invalidation). So I
>>> have changed the continuations manager to support only 1st and 3rd case.
>>>
>>> about 2nd: YAGNI (thanks Stefano for new cool phrase :))
>>
>>
>>
>> I thought 1st was older functionality, 2nd was current functionality
>> (with sitemap isolation, not sessions). 2nd as you formulated it is
>> not needed, 100% agreement here.
>>
>
> Not quite. Sitemap isolation is implied for EVERY case.
Currently - yes. But not at the time when discussion was made. I was referring
to the older discussion.
> If the user has
> a site that he/she is not able to refactor the old behaviour may be
> enabled by setting continuation-sharing-bug-compatible to true.
I know.
Vadim
Re: Continuation manager modes
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
>>
>> Users have been asking for backward compatibility (even though it's
>> broken) so you can enable the old behaviour and get warnings in your
>> log files. AFAIU some sites were relying on broken functionality too
>> much and are quite hard to refactor.
>
>
> What's those users usecase? How do they reuse the continuation across
> sitemaps? I have never had the need for this ...
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110200109324171&w=2
I do not know more. As this is a patch that does not affect whole system
much and can be easily removed by deleting 2 lines in code I applied it
without asking.
>
>> I applied the patch to 2.1.x and trunk. I think it was a mistake to do
>> it for trunk and I will remove it soon. WDYT?
>
>
> IMO we should deprecate this functionality in 2.1 (log WARNings) and
> remove it in 2.2.
This is not a functionality. This is a bug. Allowing user to invoke a
continuation in an improper context leads only to application errors.
I'd better leave it in 2.1.x as it is now:
* Continuation lookup in a wrong context yields a WARNing so user can
trace their errors.
* As the result you will get InvalidContinuationException. You can force
the continuation manager to return a requested continuation by setting
continuation-sharing-bug-compatible to true. Still you will have a
WARNing in your log every time you do that.
I'll change the continuations manager in 2.2 today. There will be no way
back to buggy behaviour.
--
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
Re: Continuation manager modes
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>
>> Leszek Gawron wrote:
>>
>>> Vadim Gritsenko wrote:
>>>
>>>> Leszek Gawron wrote:
>>>>
>>>>>
>>>>> Previously we have discussed about three continuations manager work
>>>>> modes:
>>>>>
>>>>> - standard (current functionality)
>>>>> - continuations invalidated along with session, still the continuation
>>>>> is reachable from other sessions (or no session at all)
>>>>> - fully isolated. only the session that created the continuation can
>>>>> access it.
>>
>>
>>
>> IIUC before you introduced your changes it was possible to reuse
>> continuations independently from where they have been created. What's
>> the usecase for this so that we still have have to support it?
>
> Users have been asking for backward compatibility (even though it's
> broken) so you can enable the old behaviour and get warnings in your log
> files. AFAIU some sites were relying on broken functionality too much
> and are quite hard to refactor.
What's those users usecase? How do they reuse the continuation across sitemaps?
I have never had the need for this ...
> I applied the patch to 2.1.x and trunk. I think it was a mistake to do
> it for trunk and I will remove it soon. WDYT?
IMO we should deprecate this functionality in 2.1 (log WARNings) and remove it
in 2.2.
--
Reinhard
Re: Continuation manager modes
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> Leszek Gawron wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Leszek Gawron wrote:
>>>
>>>>
>>>> Previously we have discussed about three continuations manager work
>>>> modes:
>>>>
>>>> - standard (current functionality)
>>>> - continuations invalidated along with session, still the continuation
>>>> is reachable from other sessions (or no session at all)
>>>> - fully isolated. only the session that created the continuation can
>>>> access it.
>
>
> IIUC before you introduced your changes it was possible to reuse
> continuations independently from where they have been created. What's
> the usecase for this so that we still have have to support it?
Users have been asking for backward compatibility (even though it's
broken) so you can enable the old behaviour and get warnings in your log
files. AFAIU some sites were relying on broken functionality too much
and are quite hard to refactor.
I applied the patch to 2.1.x and trunk. I think it was a mistake to do
it for trunk and I will remove it soon. WDYT?
--
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
Re: Continuation manager modes
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> Leszek Gawron wrote:
>
>> Reinhard Poetz wrote:
>>
>>> Leszek Gawron wrote:
>>>
>>>> Reinhard Poetz wrote:
>>>>
>>>>> Leszek Gawron wrote:
>>>>>
>>>>>> Vadim Gritsenko wrote:
>>>>>>
>>>>>>> Leszek Gawron wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Previously we have discussed about three continuations manager
>>>>>>>> work modes:
>>>>>>>>
>>>>>>>> - standard (current functionality)
>>>>>>>> - continuations invalidated along with session, still the
>>>>>>>> continuation
>>>>>>>> is reachable from other sessions (or no session at all)
>>>>>>>> - fully isolated. only the session that created the continuation
>>>>>>>> can
>>>>>>>> access it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> IIUC before you introduced your changes it was possible to reuse
>>>>> continuations independently from where they have been created.
>>>>> What's the usecase for this so that we still have have to support it?
>>>>
>>>>
>>>>
>>>>
>>>> Hmm after 2nd reading of your post I see I did not understand you.
>>>>
>>>> There are two orthogonal aspects of continuation visibility:
>>>> - interpreter aspect: continuation should always be resumed by the same
>>>> interpreter that created it. If not you could invoke your
>>>> continuation
>>>> in other sitemap (wrong context, resource not found exceptions,
>>>> security problems).
>>>> This case has been fixed. Still you can enable the old behaviur
>>>> because some users relied on that functionality (although broken).
>>>>
>>>> - security aspect:
>>>> - OLD MODE: you can make your continuations visible for everyone. One
>>>> user creates a continuation and passes the link to another user.
>>>> The
>>>> other one invokes it in a browser - it works. This is just as it
>>>> has
>>>> been from the start.
>>>> - NEW MODE: secure continuations.
>>>> Above behaviour creates following problems for authenticated web
>>>> applications:
>>>> * continuation ids might be stored in browser link history or page
>>>> cache.
>>>> * even though user has logged out and the session has been
>>>> invalidated the continuation might still be valid. As long as
>>>> resuming continuation does not query data from user session it
>>>> will work. This way you can have access to secured part of
>>>> application without even logging in.
>>>> So the following mode has been introduced:
>>>> * continuations are bound to the session.
>>>> * You can lookup the continuation only among the ones you have
>>>> created yourself. This way even though you "steal" a continuation
>>>> id from somewhere it's no use for you.
>>>> * When the session gets invalidated all continuations get
>>>> invalidated too.
>>>>
>>>> Hope that clears the situation.
>>>
>>>
>>>
>>>
>>> Thanks for the summary. The only point I still don't understand is:
>>> What's the usecase to resume a continuation in a different sitemap?
>>> What did people try to solve this way? (I'm asking because it sounds
>>> like a bug and not like a feature that we have to maintain.)
>>>
>> Let's ask the user himself.
>
>
> Do you remember who is it?
> Does she/he monitor cocoon-dev?
I have already posted a message to dev (you probably already know that).
He has also created a PATCH for that so we can add the same question to
bugzilla and he will get it on his private mailbox.
--
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
Re: Continuation manager modes
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>
>> Leszek Gawron wrote:
>>
>>> Reinhard Poetz wrote:
>>>
>>>> Leszek Gawron wrote:
>>>>
>>>>> Vadim Gritsenko wrote:
>>>>>
>>>>>> Leszek Gawron wrote:
>>>>>>
>>>>>>>
>>>>>>> Previously we have discussed about three continuations manager
>>>>>>> work modes:
>>>>>>>
>>>>>>> - standard (current functionality)
>>>>>>> - continuations invalidated along with session, still the
>>>>>>> continuation
>>>>>>> is reachable from other sessions (or no session at all)
>>>>>>> - fully isolated. only the session that created the continuation can
>>>>>>> access it.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> IIUC before you introduced your changes it was possible to reuse
>>>> continuations independently from where they have been created.
>>>> What's the usecase for this so that we still have have to support it?
>>>
>>>
>>>
>>> Hmm after 2nd reading of your post I see I did not understand you.
>>>
>>> There are two orthogonal aspects of continuation visibility:
>>> - interpreter aspect: continuation should always be resumed by the same
>>> interpreter that created it. If not you could invoke your continuation
>>> in other sitemap (wrong context, resource not found exceptions,
>>> security problems).
>>> This case has been fixed. Still you can enable the old behaviur
>>> because some users relied on that functionality (although broken).
>>>
>>> - security aspect:
>>> - OLD MODE: you can make your continuations visible for everyone. One
>>> user creates a continuation and passes the link to another user. The
>>> other one invokes it in a browser - it works. This is just as it has
>>> been from the start.
>>> - NEW MODE: secure continuations.
>>> Above behaviour creates following problems for authenticated web
>>> applications:
>>> * continuation ids might be stored in browser link history or page
>>> cache.
>>> * even though user has logged out and the session has been
>>> invalidated the continuation might still be valid. As long as
>>> resuming continuation does not query data from user session it
>>> will work. This way you can have access to secured part of
>>> application without even logging in.
>>> So the following mode has been introduced:
>>> * continuations are bound to the session.
>>> * You can lookup the continuation only among the ones you have
>>> created yourself. This way even though you "steal" a continuation
>>> id from somewhere it's no use for you.
>>> * When the session gets invalidated all continuations get
>>> invalidated too.
>>>
>>> Hope that clears the situation.
>>
>>
>>
>> Thanks for the summary. The only point I still don't understand is:
>> What's the usecase to resume a continuation in a different sitemap?
>> What did people try to solve this way? (I'm asking because it sounds
>> like a bug and not like a feature that we have to maintain.)
>>
> Let's ask the user himself.
Do you remember who is it?
Does she/he monitor cocoon-dev?
--
Reinhard
Re: Continuation manager modes
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> Leszek Gawron wrote:
>
>> Reinhard Poetz wrote:
>>
>>> Leszek Gawron wrote:
>>>
>>>> Vadim Gritsenko wrote:
>>>>
>>>>> Leszek Gawron wrote:
>>>>>
>>>>>>
>>>>>> Previously we have discussed about three continuations manager
>>>>>> work modes:
>>>>>>
>>>>>> - standard (current functionality)
>>>>>> - continuations invalidated along with session, still the
>>>>>> continuation
>>>>>> is reachable from other sessions (or no session at all)
>>>>>> - fully isolated. only the session that created the continuation can
>>>>>> access it.
>>>
>>>
>>>
>>>
>>> IIUC before you introduced your changes it was possible to reuse
>>> continuations independently from where they have been created. What's
>>> the usecase for this so that we still have have to support it?
>>
>>
>> Hmm after 2nd reading of your post I see I did not understand you.
>>
>> There are two orthogonal aspects of continuation visibility:
>> - interpreter aspect: continuation should always be resumed by the same
>> interpreter that created it. If not you could invoke your continuation
>> in other sitemap (wrong context, resource not found exceptions,
>> security problems).
>> This case has been fixed. Still you can enable the old behaviur
>> because some users relied on that functionality (although broken).
>>
>> - security aspect:
>> - OLD MODE: you can make your continuations visible for everyone. One
>> user creates a continuation and passes the link to another user. The
>> other one invokes it in a browser - it works. This is just as it has
>> been from the start.
>> - NEW MODE: secure continuations.
>> Above behaviour creates following problems for authenticated web
>> applications:
>> * continuation ids might be stored in browser link history or page
>> cache.
>> * even though user has logged out and the session has been
>> invalidated the continuation might still be valid. As long as
>> resuming continuation does not query data from user session it
>> will work. This way you can have access to secured part of
>> application without even logging in.
>> So the following mode has been introduced:
>> * continuations are bound to the session.
>> * You can lookup the continuation only among the ones you have
>> created yourself. This way even though you "steal" a continuation
>> id from somewhere it's no use for you.
>> * When the session gets invalidated all continuations get
>> invalidated too.
>>
>> Hope that clears the situation.
>
>
> Thanks for the summary. The only point I still don't understand is:
> What's the usecase to resume a continuation in a different sitemap? What
> did people try to solve this way? (I'm asking because it sounds like a
> bug and not like a feature that we have to maintain.)
>
Let's ask the user himself.
--
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
Re: Continuation manager modes
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>
>> Leszek Gawron wrote:
>>
>>> Vadim Gritsenko wrote:
>>>
>>>> Leszek Gawron wrote:
>>>>
>>>>>
>>>>> Previously we have discussed about three continuations manager work
>>>>> modes:
>>>>>
>>>>> - standard (current functionality)
>>>>> - continuations invalidated along with session, still the continuation
>>>>> is reachable from other sessions (or no session at all)
>>>>> - fully isolated. only the session that created the continuation can
>>>>> access it.
>>
>>
>>
>> IIUC before you introduced your changes it was possible to reuse
>> continuations independently from where they have been created. What's
>> the usecase for this so that we still have have to support it?
>
> Hmm after 2nd reading of your post I see I did not understand you.
>
> There are two orthogonal aspects of continuation visibility:
> - interpreter aspect: continuation should always be resumed by the same
> interpreter that created it. If not you could invoke your continuation
> in other sitemap (wrong context, resource not found exceptions,
> security problems).
> This case has been fixed. Still you can enable the old behaviur
> because some users relied on that functionality (although broken).
>
> - security aspect:
> - OLD MODE: you can make your continuations visible for everyone. One
> user creates a continuation and passes the link to another user. The
> other one invokes it in a browser - it works. This is just as it has
> been from the start.
> - NEW MODE: secure continuations.
> Above behaviour creates following problems for authenticated web
> applications:
> * continuation ids might be stored in browser link history or page
> cache.
> * even though user has logged out and the session has been
> invalidated the continuation might still be valid. As long as
> resuming continuation does not query data from user session it
> will work. This way you can have access to secured part of
> application without even logging in.
> So the following mode has been introduced:
> * continuations are bound to the session.
> * You can lookup the continuation only among the ones you have
> created yourself. This way even though you "steal" a continuation
> id from somewhere it's no use for you.
> * When the session gets invalidated all continuations get
> invalidated too.
>
> Hope that clears the situation.
Thanks for the summary. The only point I still don't understand is: What's the
usecase to resume a continuation in a different sitemap? What did people try to
solve this way? (I'm asking because it sounds like a bug and not like a feature
that we have to maintain.)
--
Reinhard
Re: Continuation manager modes
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> Leszek Gawron wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Leszek Gawron wrote:
>>>
>>>>
>>>> Previously we have discussed about three continuations manager work
>>>> modes:
>>>>
>>>> - standard (current functionality)
>>>> - continuations invalidated along with session, still the continuation
>>>> is reachable from other sessions (or no session at all)
>>>> - fully isolated. only the session that created the continuation can
>>>> access it.
>
>
> IIUC before you introduced your changes it was possible to reuse
> continuations independently from where they have been created. What's
> the usecase for this so that we still have have to support it?
Hmm after 2nd reading of your post I see I did not understand you.
There are two orthogonal aspects of continuation visibility:
- interpreter aspect: continuation should always be resumed by the same
interpreter that created it. If not you could invoke your continuation
in other sitemap (wrong context, resource not found exceptions,
security problems).
This case has been fixed. Still you can enable the old behaviur
because some users relied on that functionality (although broken).
- security aspect:
- OLD MODE: you can make your continuations visible for everyone. One
user creates a continuation and passes the link to another user. The
other one invokes it in a browser - it works. This is just as it has
been from the start.
- NEW MODE: secure continuations.
Above behaviour creates following problems for authenticated web
applications:
* continuation ids might be stored in browser link history or page
cache.
* even though user has logged out and the session has been
invalidated the continuation might still be valid. As long as
resuming continuation does not query data from user session it
will work. This way you can have access to secured part of
application without even logging in.
So the following mode has been introduced:
* continuations are bound to the session.
* You can lookup the continuation only among the ones you have
created yourself. This way even though you "steal" a continuation
id from somewhere it's no use for you.
* When the session gets invalidated all continuations get
invalidated too.
Hope that clears the situation.
--
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
Continuation manager modes
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> Vadim Gritsenko wrote:
>
>> Leszek Gawron wrote:
>>
>>>
>>> Previously we have discussed about three continuations manager work
>>> modes:
>>>
>>> - standard (current functionality)
>>> - continuations invalidated along with session, still the continuation
>>> is reachable from other sessions (or no session at all)
>>> - fully isolated. only the session that created the continuation can
>>> access it.
IIUC before you introduced your changes it was possible to reuse continuations
independently from where they have been created. What's the usecase for this so
that we still have have to support it?
--
Reinhard
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow
webapp/WEB-INF
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Vadim Gritsenko wrote:
> Leszek Gawron wrote:
>
>>
>> Previously we have discussed about three continuations manager work
>> modes:
>>
>> - standard (current functionality)
>> - continuations invalidated along with session, still the continuation
>> is reachable from other sessions (or no session at all)
>> - fully isolated. only the session that created the continuation can
>> access it.
>>
>> Thing is after a while I still do not see a use case for a second case
>> where continuations would be invalidated with user session but still
>> accessibe for everyone (of course before invalidation). So I have
>> changed the continuations manager to support only 1st and 3rd case.
>>
>> about 2nd: YAGNI (thanks Stefano for new cool phrase :))
>
>
> I thought 1st was older functionality, 2nd was current functionality
> (with sitemap isolation, not sessions). 2nd as you formulated it is not
> needed, 100% agreement here.
>
> Vadim
Not quite. Sitemap isolation is implied for EVERY case. If the user has
a site that he/she is not able to refactor the old behaviour may be
enabled by setting continuation-sharing-bug-compatible to true.
--
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
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow
webapp/WEB-INF
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leszek Gawron wrote:
>
> Previously we have discussed about three continuations manager work modes:
>
> - standard (current functionality)
> - continuations invalidated along with session, still the continuation
> is reachable from other sessions (or no session at all)
> - fully isolated. only the session that created the continuation can
> access it.
>
> Thing is after a while I still do not see a use case for a second case
> where continuations would be invalidated with user session but still
> accessibe for everyone (of course before invalidation). So I have
> changed the continuations manager to support only 1st and 3rd case.
>
> about 2nd: YAGNI (thanks Stefano for new cool phrase :))
I thought 1st was older functionality, 2nd was current functionality (with
sitemap isolation, not sessions). 2nd as you formulated it is not needed, 100%
agreement here.
Vadim
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow
webapp/WEB-INF
Posted by Leszek Gawron <lg...@mobilebox.pl>.
lgawron@apache.org wrote:
> Author: lgawron
> Date: Wed Dec 8 03:47:12 2004
> New Revision: 111262
>
> URL: http://svn.apache.org/viewcvs?view=rev&rev=111262
> Log:
> implement 2 modes of work for continuations manager:
> - standard, as it was up till now
> - secure in which continuations are bound to session. Only the session that created a continuation can invoke it.
> All continuations bound to session are invalidated when the session ifself gets invalidated.
> This mode is for those users who build web applications protected with authentification.
> Modified:
> cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java
> cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/WebContinuation.java
> cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf
Previously we have discussed about three continuations manager work modes:
- standard (current functionality)
- continuations invalidated along with session, still the continuation
is reachable from other sessions (or no session at all)
- fully isolated. only the session that created the continuation can
access it.
Thing is after a while I still do not see a use case for a second case
where continuations would be invalidated with user session but still
accessibe for everyone (of course before invalidation). So I have
changed the continuations manager to support only 1st and 3rd case.
about 2nd: YAGNI (thanks Stefano for new cool phrase :))
--
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