That looks so wonderful I wonder why there isn't just a new <s:form/> tag to include that functionality automatically.

Awesome Dan! It's like this that come out of the box with Seam (with JSF, this won't help Wicket) that make it a great framework to work with. This is a wonderful security piece, couple it with CAPTCHA and you have a pretty decent first round of security. If you are to use this with ICEfaces it may put a plug in XSS attacks as well because most of their components are required to be in a form anyway. I'll have to play around with this a bit and see what happens.

Solving the client-side state issue you mentioned Dan would be simple enough to solve by doing checksum of the component tree and saving it in the page a scope.

@Daniel I don't think a Seam form would be usable across the board, but it may be. Certainly an interesting idea.

The page scope is stored in the browser when using client side state saving, so unfortunate this approach would not solve anything.

You will this work with ajax requests where the same form is re-submitted several times? Is there a provision to make sure that the javax.faces.FormSignature field is re-rendered each time? Or will the protection not apply for ajax requests?

I'm actually reserving <s:form> for another purpose. As you know, <s:link> and <s:button> allow you to create bookmarkable URLs rather than form posts to request a page. I want to make <s:form> follow suit, but that is a topic for a separate post.

The checksum would have to be stored in session scope or some other persistent cache on the server. The idea behind client-side state saving is that you don't burden the server with holding large objects in memory. However, you could fit a lot of checksums into a small space. Care to do a proposal or prototype?

You could put it inside of an ajaxRendered region so that it is automatically updated. Another thing would be to make the inclusion of the render stamp (as I call it) optional, configured via the attribute allowMultipleSubmit="true". I'll give this scenario a quick test and perhaps throw in that feature. Exactly the type of feedback I am looking for.

As long as the UIToken doesn't get decoded, then the form signature stays valid. For instance, if you use ajaxSingle="true" on an input field, then it would not affect the state of the form. If you process the whole form on the server, then the UIToken needs to be in the updates. That is, unless you set the attribute I just mentioned to true, then it doesn't matter.

You know...Having the token in s:form wouldn't be a good idea, and Stuart's post made me think of that. You can essentially have the <s:token> in either a:

<h:form>
   <s:token/>
</h:form>

or a

<a4j:form>
   <s:token/>
</a4j:form>

for AJAX apps, and should work...right?

Exactly. Which is why when we introduce <s:form>, it will be for something completely unrelated to standard JSF forms.

allowMultiplePosts attribute added, default false. Please note that the preferred way is to have Ajax update the token.

I have done a quick prototype: JBSEAM-4076. I also attached a patch with the token.xml file so it can be used with facelets

Note that it's a good idea to read this knowledge base article before commenting here. We'll continually update the article as we make Seam more secure ootb.

What would be the impact of this component when running load tests. Load test applications are acting like proxy and replay the post/get requests. How could the load test app know that it should submit what's in the token field?

It depends. If your load testing driver behaves like a browser (i.e., with cookie support) then there should be zero impact since the idea of <s:token> is to ensure that the same browser submitting the form also rendered the form. In a sense, it's just asserting that the negotiation is proper. However, if the load testing driver does not behave like a browser, you will likely need to disable the tag if you find it is blocking requests. In that case, I believe you can use the rendered attribute or (better) surround it in a <c:if> tag to disable for tests.

But really, your load testing should be behaving like a proper browser and hence no impact.

Please follow up if you have trouble or disagree with this assumption (however, please at least look at how the tag works so we can discuss specifics).

Sounds like a awesome idea Dan, by the way I enjoyed your book Seam in Action. Keep up the good work!