[jsr-314-open-mirror] [jsr-314-open] [Spec-869-Specify CSRF Solution] PROPOSAL

[Andy Schwartz]

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