File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Servlets and the fly likes prevent double submit Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "prevent double submit" Watch "prevent double submit" New topic

prevent double submit

Mark Manns

Joined: Jul 06, 2006
Posts: 14

I needed to block double page submits on the server (I know, I know, lots of people say do it on the browser side, but I didn't - well, actually, I did, but didn't like the results). I used a token on the page and a servlet filter that had a token cache - I also used a timer task to clean out the cache every so often. I didn't store the token on the session because the code invalidates the session for performance reasons. It seems to work quite well so far so I thought I would share it.

Hope the code below is helpful - and if you see any issues, please post... ;)

David Newton

Joined: Sep 29, 2008
Posts: 12617

I'm not keen on doFilter's indexOf bit to determine if it should fire or not.

You're doing a forward when you block the request, but still calling the rest of the filter chain. While this might work, it's unclear and misleading. On a stylistic note, I really dislike the partial-Hungarian notation you're using. I can almost deal with parameter prefixing (although when I do this I use _xxx for members and xxx_ for parameters), but prefixing locals (and only some of them) is too much (for me).

I'd also suggest that the doFilter code is nested too deeply: turning code on its side is *not* a graph of how awesome it is ;) There's cognitive overhead when you have to "un-nest" deep structure to determine when you can stop caring about what's happening in a method, and deep structure almost always indicates possible refactorings. Inline comments almost always mean that things aren't named as clearly as they could be or possible refactorings (and represent a point of future staleness, and some duplicate what you're already logging). Consider instead something like the following (completely untested):
I agree. Here's the link:
subject: prevent double submit