Hi
I checked the problem again and it seems I misunderstood the spec
documentation. I assume the label "View Protection" in section 2.2.1
as a section that applies to all postback and non postback request,
but the context suggest that is for non postback request only, because
in postback, javax.faces.ViewState already ensures view protection.
Also, the name used for the constant:
ResponseStateManager.NON_POSTBACK_VIEW_TOKEN_PARAM
suggest that intention and the last two steps (call renderResponse() /
publish PostAddToViewEvent) are supposed to be called under the
context of a non postback request.
So, the issue should be closed as invalid, (...whoops.. ).
Anyway, as a side comment, it is curious that such param does not
have a way to inject it like ClientWindow API has. For example in
that case there are three methods:
public static void enableClientWindowRenderMode(FacesContext context)
public static void disableClientWindowRenderMode(FacesContext context)
public static boolean isClientWindowRenderModeEnabled(FacesContext context)
and in the RenderKit documentation there is an attribute called
disableClientWindow
for h:link and h:button.
Additionally, some methods were changed in ExternalContext to check this
part and inject the window id (by performance reasons).
In this case the same pattern could be applied. A param in h:link /
h:button
like enableViewProtection or something like that could be helpful.
regards,
Leonardo Uribe
2013/1/22 Leonardo Uribe <lu4242_at_gmail.com>
> Hi
>
> Checking the spec, I notice that the CSRF token
> is passed under javax.faces.Token request parameter, but the javascript
> documentation should "relay" the token like it does with
> javax.faces.ViewState or javax.faces.ClientWindow if and only if
> the token is present.
>
> I created this issue in order to fix it:
>
> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1157
>
> regards,
>
> Leonardo Uribe
>
>