Thank you for the response. I had read the multi-window topic in the documentation earlier (and also remember thinking it was outstandingly good, I thank the author). As far as how bad it can get if a user can (maliciously) concurrently access non thread safe code even within their own session, I can think of many contrived examples where the damage can be arbitrarily bad. The first that came to mind is the following list of commands.
login(root) runRestrictedCommandsForSetup() logout() login(currentUser) run(inputedUserCommands) logout() It's easy to see that when run concurrently, there is a possibility that inputedUserCommands might run as root, which can be arbitrarily bad. But there are less contrived examples too. A transaction object might end up getting shared for multiple threads, and then whole bag of race condition problems (simultaneous withdrawal from banks, etc.) are in the picture. I understand what you say about sharing conversationContexts across windows. I would rather the situation never happens. But unfortunately, as acknowledged in the documentation, it requires the co-operation of the user, which is not something I am willing to bank on. In fact, it would seem like the most natural ways for creating new tabs (right click and select open in new tab, copying the link) causes the context to be shared. So I do have to make sure that my application will at least be sound when this happens, if not predictable to the user. To me, this means I need to handle 1. Concurrent access to conversation scoped beans 2. Dirty views - i.e. when handling a request I cannot assume that the bean was in the same state as when the page that sourced this request was rendered - this subsumes your example of the deleted conversation. It looks like I don't have to worry about 1 though because of the locking on the context (except for the border case, but thats too hard to deal with, I'm going to drop it, unless Orchestra is updated). And for 2 - well, I'm still investigating how I am going to deal with that on a general basis... -Jacob On Thu, Dec 11, 2008 at 11:35 PM, Simon Kitching <skitch...@apache.org>wrote: > Hi Jacob, > > Thanks very much for your comments. > > I don't believe that "guessing the conversationcontextid" is > significant, because the id is per-session. As you point out, someone > *can* maliciously try to guess the value, thereby creating race > conditions for data *in their own session*. But I don't see any way to > expand that to corrupt data in other sessions or create a > denial-of-service for anyone else. If you can think of a way someone can > use this to affect anyone other than themself, please let me know! > > Note that having two tabs or windows with the same conversationContextId > is a bad idea; separate windows should have separate > conversationContextId values. The per-context locking is really just to > ensure that things like users double-clicking on a submit button don't > cause races. If the user can select the same view in two different > windows, and you use the same conversationContextId (or a session-scoped > backing bean) then the two windows will interact in unpleasant ways. > Having different conversationContextIds ensures that the backing bean > instance is *different* for the two windows, so no nasty interactions > occur. > > Note also that if you want multiple windows, you really should select > client-side-state-saving. > > See here for more details: > > http://myfaces.apache.org/orchestra/myfaces-orchestra-core/multiwindow.html > > That's the reason there isn't much documentation on the "conversation > locking" feature of Orchestra; apps should use different > conversationContextIds for different windows. The locking is just a > safety measure for some odd corner cases, not a major user feature. > > Regards, > Simon > > Jacob Mathew schrieb: > > It should be noted that the border case where the first request > > creates a new conversationcontext is not completely sound. In this > > scenario, no lock is acquired "because nothing else can refer to that > > newly created [conversationcontext] id until the response for this > > request has been sent back to the client browser". This is not true. > > The second request can simply guess the conversationcontext id which > > is a simple alphanumeric increment. Admittedly not a situation likely > > to happen unless someone was explicitly trying to break the > > application, but a legitimate hole nonetheless. > > > > -Jacob > > > > On Thu, Dec 11, 2008 at 4:14 PM, Jacob Mathew <jacobgmat...@gmail.com > > <mailto:jacobgmat...@gmail.com>> wrote: > > > > The source code for Orchestra provided the answer I was looking > > for. It looks like a lock is acquired on the conversationcontext > > object corresponding to the request before accessing any of the > > beans inside of a conversation. So the execution of two requests > > in the same conversationcontext will not happen concurrently, > > which mean beans in a conversation (access) scope do no, in > > general, need to be thread safe. > > > > Explicit documentation of this will probably be useful. > > > > -Jacob > > > > > > On Thu, Dec 11, 2008 at 10:52 AM, Jacob Mathew > > <jacobgmat...@gmail.com <mailto:jacobgmat...@gmail.com>> wrote: > > > > I was under the impression that beans that I set up with > > access scope will need to be thread safe because I could have > > a user open two tabs (with the same conversation context) and > > submit to the same page simultaneously (or double submit on > > the same tab). > > > > But I was running some tests and it seems like something in > > the framework is forcing accesses to my beans to be executed > > in sequence rather than simultaneously. Specifically I set it > > up so I had the first request stuck at a breakpoint and > > submitted a second request (that does not hit the breakpoint), > > but I found that *both* requests are stuck until I resume the > > thread stuck at the breakpoint. > > > > Any insights? > > > > -Jacob Mathew > > > > > > > > > -- > -- Emails in "mixed" posting style will be ignored > -- (http://en.wikipedia.org/wiki/Posting_style) > >
