RE: Does struts use tokens along with .do commands? (Was :RE: Is struts a hybrid or page-centric and servlet-centric design?)

[Colin Sampaleanu <co...@Bspark.com>]

> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Sent: September 19, 2000 2:05 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: Does struts use tokens along with .do commands? (Was :RE:
> Is struts a hybrid or page-centric and servlet-centric design?)
> 
> "Leland, Robert" wrote:
> 
> > > I would agree with that characterization, but I haven't read
> > > the book -- only the quote you cited.
> >
> > Chapter 8 ties right in with struts.
> > <Promo> Source code @ www.taglib.com,$12 online book </Promo>
> >
> > QUESTION:
> > Can struts handle multiple windows open for the same user
> > session ?
> 
> I have found this to be one of the most complicated areas to 
> deal with in
> webapp design.  The key issue is that the various windows 
> will be considered
> part of the same session under virtually all circumstances.  
> So the real issue
> becomes "does my application deal correctly with multiple 
> flows of control
> operating in the same session at the same time?"  This is 
> where it gets tricky.
> 
> > In WDJSP each command he sent from the servlet to the
> > JSP page contained a token, a time stamp with md5 encoding.
> > So commands can only be performed only once, and could also 
> be made to
> > timeout after a while.
> 
> Struts doesn't have any particular support for this 
> technique, although it
> sounds like the same principles would apply.  One thing you 
> can look at,
> though, is running your application session-less, using only 
> request attributes
> instead.  This takes a little more work to set up (your forms 
> and form beans
> need to carry around any state info you need as hidden 
> variables), but it
> elegantly deals with the multi-window scenario, because the 
> flow of control for
> each window is independent.

One thing that bears mentioning in this kind of setup is that you need to be
careful about your security. You are exposing pieces of your infrastructure
in ways that a session variable wouldn't. For example, if there is a
customer ID or order ID passed along as a request parameter, your backend
has to either make sure the current use has rights to the data for that
object ID, or else if you don't want to go to that level the object ID
itself can be made hard to fake (e.g. use something like a GUID or hash).
Not necessarilly that big a deal, but it's always worth thinking about the
security aspects...