Token question

[Derrick Koes <De...@skillsoft.com>]

if (null == request.getParameter(Constants.TOKEN_KEY)) {
    saveToken(request);
}
else {
    if (!isTokenValid(request, true)) {
        response.sendError(HttpServletResponse.SC_CONFLICT, "The request received was out             
            of sequence, perhaps due to a second submit, refresh, or unexpected post
                data.");
       return null;
    }
}

I have this code in my execute method.  The request won't have a token unless it is a form submission.  Therefore, I think I can safely get away with this code.

Is this true?  I believe using tokens is the preferred way to handle duplicate form submits.  However, I'm not clear on the best way to do this.

Thanks,
Derrick

Re: Token question

["Michael J." <jm...@gmail.com>]

On 4/19/05, Derrick Koes <De...@skillsoft.com> wrote:
> 
> if (null == request.getParameter(Constants.TOKEN_KEY)) {
>     saveToken(request);
> }
> else {
>     if (!isTokenValid(request, true)) {
>         response.sendError(HttpServletResponse.SC_CONFLICT, "The request received was out
>             of sequence, perhaps due to a second submit, refresh, or unexpected post
>                 data.");
>        return null;
>     }
> }
> 
> I have this code in my execute method.  The request won't have a token unless it is a form submission.  Therefore, I think I can safely get away with this code.
> 
> Is this true?  I believe using tokens is the preferred way to handle duplicate form submits.

My strong opinion is that webapp should not have "Do you want to
resubmit POSTDATA?" situations. You can get into resubmit in one of
the following cases:

* reloading result page using Refresh/Reload browser button (explicit
page reload, implicit resubmit of request);
* clicking Back and then Forward browser buttons (implicit page reload
and implicit resubmit of request);
* returning back to HTML FORM after submission, and clicking Submit
button on the form again (explicit resubmit of request)
* quickly submitting page again, before it was replaced in browser by
a response page.

The first two issues can be solved, if you redirect from action to
JSP, instead of forwarding from action to JSP. The last one can be
solved with immediate disabling submit button after submit, and with
locking resources on the server when request is received.

The third one, explicit resubmit, can be solved on domain model level.
Say, you submitted information like shopping cart, for the first time.
You lock the cart on the server, process it, and then dispose it. The
user goes back, tries to submit the same cart, but oops! the cart was
already processed and disposed, so you just show explanatory message.
No tokens.

Even better, if your pages are non-cachable and are always reflect
server state, then when a user goes back, browser tries to reload
shopping cart, but it was already disposed. Then you show error page
or starting page, whatever you like. Again, no harm done and no
tokens.

Tokens are pure web framework solution. They do not know about your
domain model. But you do, so use this knowledge. With good domain
model tokens are not needed, and you will be able to build more robust
and user-friendly application.

If interested, read more here:
  http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost
  http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost2

Best regards,
   Michael Jouravlev.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org