[jira] [Commented] (MYFACES-4033) Weird behavior with form authencation / forward / restore view
[ https://issues.apache.org/jira/browse/MYFACES-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15157688#comment-15157688 ] Thomas Andraschko commented on MYFACES-4033: I think that HtmlResponseStateManager#isPostback should also check the HTTP method and not only the VIEW_STATE_PARAM. WDYT? > Weird behavior with form authencation / forward / restore view > -- > > Key: MYFACES-4033 > URL: https://issues.apache.org/jira/browse/MYFACES-4033 > Project: MyFaces Core > Issue Type: Bug >Reporter: Thomas Andraschko >Assignee: Leonardo Uribe > > Following case: > 1) visit login.xhtml > with > > > > > > 2) submit (non-ajax post) with invalid user > 3) tomcat forwards to the loginError.xhtml > 4) MyFaces tries to restore the view with the ViewState from login.xhtml > 5) ViewExpired occurs > IMO MyFaces should not restore the view after a forward -> > if (post && forward) { >-> new view > } > else { >-> restore > } > It also works fine in Mojarra. > [~lu4242] How would you fix it? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4033) Weird behavior with form authencation / forward / restore view
[ https://issues.apache.org/jira/browse/MYFACES-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15157953#comment-15157953 ] Leonardo Uribe commented on MYFACES-4033: - I have checked the documentation related to isPostback and I don't see anything wrong. The spec (section 2.2.1) says this "... Get that RenderKit’s ResponseStateManager and call its isPostback() method, passing the current FacesContext. If the current request is an attempt by the servlet container to display a servlet error page, do not interpret the request as a postback, even if it is indeed a postback. ..." That logic is on RestoreViewExecutor. The javadoc says this: "... The implementation if this method for the Standard HTML RenderKit must consult the ExternalContext's requestParameterMap and return true if and only if there is a key equal to the value of the symbolic constant VIEW_STATE_PARAM. ..." The implementation in MyFaces does what the spec says. If the request is an error request sent by the container, "javax.servlet.error.message" request param should be set. The HTTP method is never used by JSF spec, because in JSF 1.1/1.2 it was not possible to grab it (servlet 2.4/2.5). If Mojarra does something special, it is not written in the spec. > Weird behavior with form authencation / forward / restore view > -- > > Key: MYFACES-4033 > URL: https://issues.apache.org/jira/browse/MYFACES-4033 > Project: MyFaces Core > Issue Type: Bug >Reporter: Thomas Andraschko >Assignee: Leonardo Uribe > > Following case: > 1) visit login.xhtml > with > > > > > > 2) submit (non-ajax post) with invalid user > 3) tomcat forwards to the loginError.xhtml > 4) MyFaces tries to restore the view with the ViewState from login.xhtml > 5) ViewExpired occurs > IMO MyFaces should not restore the view after a forward -> > if (post && forward) { >-> new view > } > else { >-> restore > } > It also works fine in Mojarra. > [~lu4242] How would you fix it? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4033) Weird behavior with form authencation / forward / restore view
[ https://issues.apache.org/jira/browse/MYFACES-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158642#comment-15158642 ] Thomas Andraschko commented on MYFACES-4033: Hmm, you are absolulety right. I just debugged both mojarra and myfaces and in mojarra the view is just restored... In MyFaces restoring the view fails (which is correct). "javax.servlet.error.message" is not set - so we restore the view. The question is, would it break other cases if we would also check for a forward before trying to restore the view? It's working fine in jetty because jetty redirects instead a forward if the auth fails. > Weird behavior with form authencation / forward / restore view > -- > > Key: MYFACES-4033 > URL: https://issues.apache.org/jira/browse/MYFACES-4033 > Project: MyFaces Core > Issue Type: Bug >Reporter: Thomas Andraschko >Assignee: Leonardo Uribe > > Following case: > 1) visit login.xhtml > with > > > > > > 2) submit (non-ajax post) with invalid user > 3) tomcat forwards to the loginError.xhtml > 4) MyFaces tries to restore the view with the ViewState from login.xhtml > 5) ViewExpired occurs > IMO MyFaces should not restore the view after a forward -> > if (post && forward) { >-> new view > } > else { >-> restore > } > It also works fine in Mojarra. > [~lu4242] How would you fix it? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4033) Weird behavior with form authencation / forward / restore view
[ https://issues.apache.org/jira/browse/MYFACES-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159725#comment-15159725 ] Leonardo Uribe commented on MYFACES-4033: - MyFaces uses some identifiers to detect when a view state is valid or not, to avoid use one view state in other different view. If the fix cannot be done from outside, maybe we could introduce a web config parameter by default disabled to check that condition. I agree this is weird (I have experienced this behavior on the past). The problem is how to detect the "forward". > Weird behavior with form authencation / forward / restore view > -- > > Key: MYFACES-4033 > URL: https://issues.apache.org/jira/browse/MYFACES-4033 > Project: MyFaces Core > Issue Type: Bug >Reporter: Thomas Andraschko >Assignee: Leonardo Uribe > > Following case: > 1) visit login.xhtml > with > > > > > > 2) submit (non-ajax post) with invalid user > 3) tomcat forwards to the loginError.xhtml > 4) MyFaces tries to restore the view with the ViewState from login.xhtml > 5) ViewExpired occurs > IMO MyFaces should not restore the view after a forward -> > if (post && forward) { >-> new view > } > else { >-> restore > } > It also works fine in Mojarra. > [~lu4242] How would you fix it? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4033) Weird behavior with form authencation / forward / restore view
[ https://issues.apache.org/jira/browse/MYFACES-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159731#comment-15159731 ] Thomas Andraschko commented on MYFACES-4033: Detecting a forward is easy -> if (request.getAttribute("javax.servlet.forward.request_uri") != null) { // forward } I'm just not sure if there is a case when restoring the view after a forward could be valid. What about url rewrites? do they use forwards internally? Maybe a valid check is to check the request Url, too (which is j_security_check). > Weird behavior with form authencation / forward / restore view > -- > > Key: MYFACES-4033 > URL: https://issues.apache.org/jira/browse/MYFACES-4033 > Project: MyFaces Core > Issue Type: Bug >Reporter: Thomas Andraschko >Assignee: Leonardo Uribe > > Following case: > 1) visit login.xhtml > with > > > > > > 2) submit (non-ajax post) with invalid user > 3) tomcat forwards to the loginError.xhtml > 4) MyFaces tries to restore the view with the ViewState from login.xhtml > 5) ViewExpired occurs > IMO MyFaces should not restore the view after a forward -> > if (post && forward) { >-> new view > } > else { >-> restore > } > It also works fine in Mojarra. > [~lu4242] How would you fix it? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MYFACES-4033) Weird behavior with form authencation / forward / restore view
[ https://issues.apache.org/jira/browse/MYFACES-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159836#comment-15159836 ] Leonardo Uribe commented on MYFACES-4033: - There is one case when a forward is done. The class org.apache.myfaces.view.jsp.JspViewDeclarationLanguage has a call (on buildView(...)) to externalContext.dispatch(...) which calls requestDispatcher.forward(...). I think if facelets only is enabled, it is safe to assume a "forward" leads to a new view. In MyFaces Core there is no server-side url rewrites, but the client window could force a client-side url rewrite. JSF was done to be container-agnostic, even if it is somewhat tied to servlet technology. I do not like the idea of check the incoming request url, but if it is justified it is ok to include it. > Weird behavior with form authencation / forward / restore view > -- > > Key: MYFACES-4033 > URL: https://issues.apache.org/jira/browse/MYFACES-4033 > Project: MyFaces Core > Issue Type: Bug >Reporter: Thomas Andraschko >Assignee: Leonardo Uribe > > Following case: > 1) visit login.xhtml > with > > > > > > 2) submit (non-ajax post) with invalid user > 3) tomcat forwards to the loginError.xhtml > 4) MyFaces tries to restore the view with the ViewState from login.xhtml > 5) ViewExpired occurs > IMO MyFaces should not restore the view after a forward -> > if (post && forward) { >-> new view > } > else { >-> restore > } > It also works fine in Mojarra. > [~lu4242] How would you fix it? -- This message was sent by Atlassian JIRA (v6.3.4#6332)