[
https://issues.apache.org/jira/browse/MYFACES-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194833#comment-16194833
]
Bill Lucy commented on MYFACES-4058:
------------------------------------
I've been looking into this issue as well; in the scenario I'm investigating,
protected views are broken in Safari. Similar to the other posts here, I can
see an Origin header added by Safari to a non-CORS request.
I can see that JSF 2.2 section 2.2.1 says we should be checking the Origin
header in the same way we check the Referer header.. but that doesn't make
sense: the header is not intended to contain any path info.
(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin) So it looks
like checking the Origin header in
RestoreViewExecutor.checkRefererOrOriginHeader() will always fail.
Checking the Origin header against the ExternalContext's host and port makes
sense, but not the full path. Changing the default behavior here would make
sense to me, given my current understanding, but a custom param would work,
given the language in the spec. [~lu4242] what are your thoughts?
> ProtectedViewException for a protectedview access while checking the
> OriginHeader for appContextPath
> ----------------------------------------------------------------------------------------------------
>
> Key: MYFACES-4058
> URL: https://issues.apache.org/jira/browse/MYFACES-4058
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects Versions: 2.2.6
> Environment: Windows, JSF 2.2
> Reporter: Dinesh Kumar A S
>
> Getting ProtectedViewException while accessing a protectedview/xhtml, while
> checking the OriginHeader for appContextPath..
> SO reference :
> http://stackoverflow.com/questions/38308431/jsf-2-2-protectedviewexception-due-to-origin-header-and-appcontextpath-mismatch
> Any help is much appreciated.
> Does the "Origin" request-header is supposed to have the appContextPath in
> the path/urlInfo ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
