The JSF specification section 2.2.1 "Restore View" states the following:
View Protection
Call ViewHandler.getProtectedViewsUnmodifiable() to determine if the view for this viewId is protected. If not, assume the requested view is not protected and take no additional view protection steps. Obtain the value of the value of the request parameter whose name is given by the value of ResponseStateManager.NON_POSTBACK_VIEW_TOKEN_PARAM. If there is no value, throw ProtectedViewException. If the value is present, compare it to the return from ResponseStateManager.getCryptographicallyStrongTokenFromSession(). If the values do not match, throw ProtectedViewException. If the values do match, look for a Referer [sic] request header. If the header is present, use the protected view API to determine if any of the declared protected views match the value of the Referer header. If so, conclude that the previously visited page is also a protected view and it is therefore safe to continue. Otherwise, try to determine if the value of the Referer header corresponds to any of the views in the current web application. If not, throw a ProtectedViewException. If the Origin header is present, additionally perform the same steps as with the Referer header.
It seems that both implementations (Mojarra and MyFaces) assume there is an app path associated with the Origin header as a result of the bolded text above.
I propose we update the test to clarify this is not correct.
The JSF specification section 2.2.1 "Restore View" states the following:
It seems that both implementations (Mojarra and MyFaces) assume there is an app path associated with the Origin header as a result of the bolded text above.
I propose we update the test to clarify this is not correct.
See the following MyFaces JIRA for additional details and testing: https://issues.apache.org/jira/browse/MYFACES-4058