jakartaee / faces

Jakarta Faces
Other
102 stars 54 forks source link

ProtectedViewException for a protectedview access while checking the OriginHeader #1451

Open eclipse-faces-bot opened 6 years ago

eclipse-faces-bot commented 6 years ago

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.

See the following MyFaces JIRA for additional details and testing: https://issues.apache.org/jira/browse/MYFACES-4058

eclipse-faces-bot commented 5 years ago