Re: [jsr-314-open-mirror] [jsr-314-open] [Spec-869-Specify CSRF Solution] PROPOSAL
Thanks for the comments Roger.
On 10/22/10 9:37 AM, Roger Kitain wrote:
Custom forms would need to follow the new rendering requirements for
CSRF (described in
renderkit docs).
I reviewed the relevant render kit docs:
Render a hidden field named javax.faces.Token using the
ResponseStateManager.VIEW_TOKEN_PARAM constant if the configuration
option javax.faces.CSRF_ALGORITHM is set to either of the key words
form or all. The name must be namespaced with the enclosing form's
client identifier. Render the value of this hidden field, known as the
"token value", as a cryptographically produced random generated value
(known as the "secret key") retrieved from the session. If the "secret
key" does not already exist in the session, create the random value
and store it in the session. Implementations may choose to produce a
more complex token value by combining the random "secret key" with
other values. The default value for the javax.faces.CSRF_ALGORITHM
configuration option is none
This seems okay, however: doesn't the FormRenderer and the
RestoreViewPhase implementation need to be in sync on what the
token/secret key is? Is there a way to do this without replacing the
Lifecycle?
In 2.2, we could further simplify this by providing API
"hooks".
By default, CSRF is not enabled, so existing apps continue to work.
Cool. I still want to make sure that when this is enabled we have some
way that custom form components can participate (even if this means some
work for the form component/renderer implementation).
Oh, btw, one thing that I was still unclear on... Are we also solving
the double-submit problem - ie. do we re-generate the token on each submit?
Andy