Regarding the generation of the hash, would s:token also address the possibility of replay attacks? (Where the same request can be sent multiple times without having to modify the contents, but still have a malicious effect). If it doesn't, I would consider looking at also generating a random number when rendering s:token, and that random number is stored on the server viewstate and client side  (for each request), and used in calculating the hash. This number would change with each request.

  If this is already address issue, please ignore. My knowledge of internal JSF workings (form client ID for example), is limited compared to that of hashing/replay attacks/etc.

Ashish Tonse

On Wed, Mar 11, 2009 at 10:23 AM, Dan Allen <dan.j.allen@gmail.com> wrote:
Issue created and initial concept patch provided here https://jira.jboss.org/jira/browse/JBSEAM-4007


--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.

_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev