[jira] [Commented] (MYFACES-4058) ProtectedViewException for a protectedview access while checking the OriginHeader for appContextPath
[ https://issues.apache.org/jira/browse/MYFACES-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209862#comment-16209862 ] Leonardo Uribe commented on MYFACES-4058: - I think if Origin header should not contain app path, it is ok to do so, because the intention was to check the origin header. A context param org.apache.myfaces.STRICT_JSF_2_ORIGIN_HEADER_APP_PATH could work. > 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 > Attachments: MYFACES-4058.patch > > > 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)
[jira] [Commented] (MYFACES-4164) Unexpected behavior when javax.faces.ViewState is set to "stateless" in a State view
[ https://issues.apache.org/jira/browse/MYFACES-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209837#comment-16209837 ] Leonardo Uribe commented on MYFACES-4164: - Strange, I remember there was a check in some place for that condition (stateful view with stateless view state). > Unexpected behavior when javax.faces.ViewState is set to "stateless" in a > State view > > > Key: MYFACES-4164 > URL: https://issues.apache.org/jira/browse/MYFACES-4164 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.12, 2.3.0-beta >Reporter: Eduardo Breijo > Attachments: ProtectedViewStateless.war > > > I have encountered an issue or an unexpected behavior with a stateless value > of “javax.faces.ViewState” hidden input. > Let’s say you navigate to a state view. When the value attribute of > “javax.faces.ViewState” is changed manually using browser’s developer tools, > the application can prevent CSRF attack by throwing a ViewExpiredException. > However, if you modify the value to be “stateless”, then no > ViewExpiredException is thrown. > Even if you add View Protection to the state view, and modify the value to be > “stateless”, no exception is thrown. > The following JIRA issue said that this should be prevented with View > Protections but it seems that’s not working. > https://issues.apache.org/jira/browse/MYFACES-3714 > Comparing this behavior with Mojarra, if the you modify the value to be > “stateless”, then the following exception is thrown: > javax.faces.FacesException: Unable to restore view /stateView.xhtml > > com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:255) > > com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:157) > > javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:125) > > com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:204) > com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100) > I have provided a sample app that demonstrates this behavior. > Instructions to recreate the behavior on Tomcat: > 1)Deploy the app on tomcat > 2)Drive a request to > http://localhost:8080/ProtectedViewStateless/index.xhtml > 3)Click the “Navigate to State View” link > 4)Open the Browser’s Developer Tools and modify the value of > “javax.faces.ViewState” to “stateless” > 5)Click the “Go to Final View” button. No exception is thrown. > If you change the MyFaces bundle to a Mojarra bundle and repeat the same > steps, you’ll get the exception I mentioned above. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4058) ProtectedViewException for a protectedview access while checking the OriginHeader for appContextPath
[ https://issues.apache.org/jira/browse/MYFACES-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209824#comment-16209824 ] Thomas Andraschko commented on MYFACES-4058: +1 for a spec issue IMO (!) if the current spec is unable to work, we can also do the change without a context param > 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 > Attachments: MYFACES-4058.patch > > > 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)
[jira] [Commented] (MYFACES-4058) ProtectedViewException for a protectedview access while checking the OriginHeader for appContextPath
[ https://issues.apache.org/jira/browse/MYFACES-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209813#comment-16209813 ] Paul Nicolucci commented on MYFACES-4058: - Would it be ok to make this change in MyFaces and at the same time open a spec issue so that it can be clarified in the specification? Since Mojarra behaves the same way as MyFaces right now what should we do regarding the context-parameter? > 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 > Attachments: MYFACES-4058.patch > > > 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)
[jira] [Created] (MYFACES-4164) Unexpected behavior when javax.faces.ViewState is set to "stateless" in a State view
Eduardo Breijo created MYFACES-4164: --- Summary: Unexpected behavior when javax.faces.ViewState is set to "stateless" in a State view Key: MYFACES-4164 URL: https://issues.apache.org/jira/browse/MYFACES-4164 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.3.0-beta, 2.2.12 Reporter: Eduardo Breijo Attachments: ProtectedViewStateless.war I have encountered an issue or an unexpected behavior with a stateless value of “javax.faces.ViewState” hidden input. Let’s say you navigate to a state view. When the value attribute of “javax.faces.ViewState” is changed manually using browser’s developer tools, the application can prevent CSRF attack by throwing a ViewExpiredException. However, if you modify the value to be “stateless”, then no ViewExpiredException is thrown. Even if you add View Protection to the state view, and modify the value to be “stateless”, no exception is thrown. The following JIRA issue said that this should be prevented with View Protections but it seems that’s not working. https://issues.apache.org/jira/browse/MYFACES-3714 Comparing this behavior with Mojarra, if the you modify the value to be “stateless”, then the following exception is thrown: javax.faces.FacesException: Unable to restore view /stateView.xhtml com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:255) com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:157) javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:125) com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:204) com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100) I have provided a sample app that demonstrates this behavior. Instructions to recreate the behavior on Tomcat: 1) Deploy the app on tomcat 2) Drive a request to http://localhost:8080/ProtectedViewStateless/index.xhtml 3) Click the “Navigate to State View” link 4) Open the Browser’s Developer Tools and modify the value of “javax.faces.ViewState” to “stateless” 5) Click the “Go to Final View” button. No exception is thrown. If you change the MyFaces bundle to a Mojarra bundle and repeat the same steps, you’ll get the exception I mentioned above. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
