Hi
Ok, now I get the intention. Thanks for the clarification.
I was expecting the javadoc of
ExternalContext.encodeBookmarkableURL(String baseUrl,
Map<String,List<String>> parameters)
ExternalContext.encodeRedirectURL(String baseUrl,
Map<String,List<String>> parameters)
or the javadoc of
ViewHandler.getBookmarkableURL(FacesContext context, String viewId,
Map<String,List<String>> parameters, boolean includeViewParams)
ViewHandler.getRedirectURL(FacesContext context, String viewId,
Map<String,List<String>> parameters, boolean includeViewParams)
include the specified logic. By deduction, I suppose the logic should
be in ViewHandler.
regards,
Leonardo Uribe
2013/2/5 Edward Burns <edward.burns_at_oracle.com>:
>>>>>> On Mon, 4 Feb 2013 19:35:31 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
>
> LU> Hi
> LU> I finally created this issue:
>
> LU> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1161
>
> LU> CSRF protection cannot be used "out of the box" without create a
> LU> custom component or override forcefully ExternalContext
>
> The CSRF protection feature was desgined to be similar to how view
> protection works in Servlet. Specifically, the designation of which
> views are protected is done in a central place rather than in any
> specific views, or in specific UI components *within* views.
>
> Leonardo, why do you feel it is necessary to pollute the view with this
> information? Looking at the latest spec [1], look at the generated HTML
> for the "faces-config XML Schema Documentation" link. Within there look
> at the spec for faces-config-protected-viewsType. It says.
>
> Any view that matches any of the url-patterns in this element may only
> be reached from another JSF view in the same web application. Because
> the runtime is aware of which views are protected, any navigation from
> an unprotected view to a protected view is automatically subject to
> protection.
>
> I really don't see why this has to be a per-component decision. I'm
> going to close this as "works as designed" but if after reading this
> response you *and someone else on this list* disagree, please re-open
> it. At this point, I welcome all challenges, but I have a high bar if I
> think it's already designed correctly.
>
> Remember, as we discussed yesterday, getting the view loading story
> right with respect to composite components, templates and regular views
> within resource libraries, contracts, and flows, is my most pressing
> concern, spec wise. Anything else takes away time from that vital
> concern.
>
> Ed
>
> [1] http://jsf-spec.java.net/SNAPSHOT/javadoc/