Hi Pawel,
Paweł Wielgus wrote: > >> Agreed, but how do you check that the hidden ids that come back with the >> submit are the ones that >> you sent in the first place? It's not that hard to use something like >> HttpClient to send malicious POST's > > Yes, it's possible but not likely, in general users use multiple tabs, > and they don't use HttpClients. > If You would like to be protected from params manipulating, > another mechanism would be needed. > > Unlikely in an Intranet environment prehaps, but there are a lot of nasty people on the internet who *could* programmatically attack your application. Whether you worry about that depends I suppose on the sensitivity of your web application. Paweł Wielgus wrote: > > Then if any POST need no session data they won't interrrupt each other, > such POSTs are self-sufficient. > And how do you avoid using the session - shoving everything into request scope and returning it through hidden fields is insecure. Wasn't it this approach of storing all state on the client through the HttpRequest that drew so much flack for the early JSF implementations. Paweł Wielgus wrote: > > > As far as i remember MessageStoreInteceptor is needed when after > submit a redirect is called and You don't want to lose errors, and it > will not function properly when user will submit many forms for the > same object in one moment. > > As Dave said, check out Seam framework, > there is also a thread (month or years ago) on this group > where people where talking about adding such functionality to struts2. > Actually, looking at some of the source code, there's quite a lot that could potentially break in Struts if there was heavy use of multiple tabs - ScopedModelDrivenInterceptor, for example, just stores things in the Session under a known key. Preliminary poking around in Seam, and it looks like their HttpSession, contains something on the lines of a Map<Key,Map<String,Object>> where Key uniquely identifies a "tab conversation" and the Map<String,Object> is similair to the current Struts view of the session from SessionAware. The conversation is initiated serverside and the key is passed backwards and forwards via the HttpRequest. (Obviously it's a tad more sophisticated than that, but that seems to be the essence) http://myfaces.apache.org/orchestra/myfaces-orchestra-core/multiwindow.html has an interesting take on the issues involved with multi tab processing and concludes that none of Spring WebFlow, JBoss Seam or Apache Wicket actually get it right 100%. Given that multi tab browsing has been around for a while now and even core Struts seems to assume single window access to the session is the norm, perhaps I'm just being over cautious. Regards -- View this message in context: http://old.nabble.com/Struts-2%2C-Session-Management-and-%22WorkFlow%22.-tp29726121p29727862.html Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org