This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
#1 is taken care of by SWF. It uses the POST-REDIRECT-GET pattern, so when a page is rendered to the user, the URL is stable, and has no side effects if you should refresh it. If you want to prevent the user from even going back to the previous page (or beyond) and submitting again, you can discard or invalidate the history (saved snapshots of state). You can do this with the "history" attribute of the transition away from the sensitive state:
This thread might also be helpful, in terms of dealing with exceptions when you use the browser back button after history has been invalidated.
I don't think SWF has built in support for this (someone correct me if I'm wrong), but you should be able to implement it yourself with the UUID class (in Java.util for Java 5 and higher) to get a random UUID (your token), and a FlowExecutionListenerAdapter (you'll need to add it to your flow config), overriding the viewRendering() to create and add your token to whichever scopes you need (view and request, I think) and resuming() or transitionExecuting() to compare the tokens on a submit. Of course, you'll need to add the token's long value to any forms you want as a hidden form parameter. It might also help to only perform this token check if your transition has a custom attribute to signal that a token check should be performed for the transition to succeed.
As a bonus, the token implementation will probably give you some protection against XSS attacks.
Last edited by InverseFalcon; Feb 24th, 2010, 02:26 PM.
Reason: request scope is probably a better scope than flash for saving the token
1) I have implemented as you have suggested and it worked. But what I observed is, exception in the Filter class gets caught in Exception block and not in 'FlowExecutionRestorationFailureException' block which should be case.
2) Regarding XSS: I observed that without doing anything web flow is taking care of this point. In text input box, I entered
and in the confirmation screen value was displayed as is and no popup. Am I missing anything.
Right, forgot to mention that SWF likes to wrap its exceptions. I'm also catching Exception, then checking to see if its cause is a FlowExecutionRestorationFailureException. I think that should work for you.
Whoops, I meant CSRF protection, not XSS. When each form submission requires a unique, request-specific token, most CSRF attacks fail. SWF's flow execution ID provides some protection in this area, but the execution and snapshot numbers increment predictably, and are considered valid for as long as the snapshot is around, so a token mechanism is stronger.