On Fri, 1 Feb 2002 19:10:33 -0600, Judson Lester <[EMAIL PROTECTED]> wrote:
> On Friday 01 February 2002 06:29 pm, Ovidiu Predescu wrote: > > Hi Judson, > > > > On Fri, 1 Feb 2002 12:53:32 -0600, Judson Lester <[EMAIL PROTECTED]> wrote: > > > > > Would a session not be the appropriate place to store continuations > > > > > and associated data? The URL strikes me as a really bad idea, as it > > > > > should be a logic-level address (ie foo.com/add) rather than an > > > > > implementation level (foo.com/add/4ff.) Under what circumstances > > > > > might you wish not to resort to session? > > > > > > > > This is a good question. > > > > > > > > If you look at the concept of session in the servlet environment, you > > > > realize it's only a way to save state across HTTP requests. But with > > > > continuations, you no longer need this! The continuation saves in it > > > > the complete stack frame of calls, including local variables. When a > > > > continuation is resurrected, it will contain the values for all the > > > > local variables you declare. > > > > > > > > What you're referring to is probably not session, but cookies. The > > > > problem is you cannot use cookies to encode the continuation's URL, as > > > > this would prevent the user from hitting the back button. This happens > > > > because the cookie is set globally, for the whole domain. Hitting the > > > > back button will not change the cookie's value to point to the right > > > > page. > > > > > > > > So clearly you need a way to encode the continuation's URL in the page > > > > itself, rather than assign it to a cookie. > > > > > > I personally agree with Allan, that trying to encode a user in his URL is > > > problematic. However, I don't see why it would be impossible to > > > establish a cookie backed session, and then store the coninuation tree in > > > the session, with a map of URLs to continuations. This gives you the > > > session-hijacking protection established by Servlet session scopes, but > > > allows you to also get back-button-to-previous-continuation feature that > > > Ovidiu has slowly brought me to understand completely. > > > > Ah, I see your point. Allan and you propose a two level indirection > > scheme to obtain the continuation. The first level is keyed by the > > cookie, and points to the session object. The second level is keyed by > > the URL and points to the continuation. > > > > This would probably work fine if an URL has exactly one continuation > > associated. However I'm afraid this may not be the case, an > > application may use the same URL multiple times to do different > > tasks. > > > > Suppose we have this case: > > > > History stack > > /a > > /b > > /c > > /a > > /d > > => /a > > > > I think you're breaking the continuation addressing in the wrong place. > > What I'm thinking (and perhaps so is Allan) is that any one continuation is > essentially a specific page served. So if I go to a website, browse around a > little, and follow a link back to the homepage, then the two different home > page visits are different continuations, (although if a click back, it'd be > the same continuation). N'ce pas? Further if I visit the homepage at the > same instant that you do, that's two different continuations. Yes, that's right, each visit would become a continuation. And each user will get his/her own continuation for visiting the same page. > I think what I'm trying to make sure that the difference between > Judson's continuations and Ovidiu's continuations is that I have a > different cookie than you do, but the difference between my > coninuations might be encoded in the URL. > > History stack > /a-3 > /b-1 > /c-1 > /a-2 > /d-1 > /a-1 > > This would mean that I couldn't look over your shoulder, write down > your URL, walk across the lab and hijack your session. Better still > would be if the URL weren't the encoding system, because there also > the issue of people bookmarking a continuation, or trying to screw > the system up by writing their own URLs. Bookmarking in fact should be allowed. If the user bookmarked a page whose continuation expired on the server side, an appropriate error message should be provided, and the user redirected to the appropriate page. > > Can you see this point of view? I could also see how this might be > super-trivial and something you'd ignored. But rewriting URLs to > mark session has significant issues which continuations inherit. I think I understand your point now. One thing to keep in mind though, is that the continuation identifier is not going to be a simple number, but a sufficiently complex, random identifier, very similar with the session identifier. What you're saying is that for security reasons we should combine the continuation id with a cookie stored on the system. While I think this makes a lot of sense in many Web applications that do need security, others don't need this extra layer. In addition to this, some browsers, notably WAP devices, don't support cookies, or the user may decide to disable them. I think from Cocoon's point of view, the mechanism used to identify the continuation should be completely customizable. Whether the developer wants to encode the continuation id in the URL, or as an argument of a GET/POST request, or use both continuation id and cookie id, they should all be available options. Regards, Ovidiu --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
