[
https://issues.apache.org/jira/browse/MYFACES-3714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13753216#comment-13753216
]
Leonardo Uribe commented on MYFACES-3714:
-----------------------------------------
Committed solution for this one. It seems the issues between view protection
and stateless views will be clarified in a further version of the spec. For now
I think it is ok to consider stateless views as unprotected, and enforce
protected views to be not stateless.
> Implement stateless mode using f:view "transient" attribute
> -----------------------------------------------------------
>
> Key: MYFACES-3714
> URL: https://issues.apache.org/jira/browse/MYFACES-3714
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-344
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
>
> Implement stateless mode using f:view "transient" attribute
> The big problem with this stuff is what happen when view protection is
> considered and the resulting relationship between the state mode used (client
> or server) and mixing everything together.
> For example, view protection relies on what's inside javax.faces.ViewState
> hidden field and how it is encoded. Theorically javax.faces.ViewState
> protects against CSRF attacks, but with a special stateless token it could be
> possible to use that token into non stateless views. We should prevent that
> adding proper checks into the StateManagementStrategy and the Restore View
> phase.
> In theory, it is necessary to extend
> org.apache.myfaces.application.StateCache abstract class to reflect the
> necessary logic to ensure protected views are always secured, even if they
> are declared as stateless.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
