[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-4032) upgrade common-beanutils to 1.9.2 to resolve security vulnerability
[ https://issues.apache.org/jira/browse/MYFACES-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159734#comment-15159734 ] Leonardo Uribe commented on MYFACES-4032: - BeanIntrospector is never used, so there is no place to use the property in the code. > upgrade common-beanutils to 1.9.2 to resolve security vulnerability > --- > > Key: MYFACES-4032 > URL: https://issues.apache.org/jira/browse/MYFACES-4032 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.8, 2.2.9 >Reporter: Santosh P >Assignee: Leonardo Uribe >Priority: Critical > Fix For: 2.2.10 > > > Hello, > We have been reported for security vulnerable library common-beanutils-1.8.3. > Myfaces-impl is dependent on this library and which is downloaded to > application WEB-INF/lib while packaging. > Clould you please upgrade to latest release 1.9.2 of common-beanutils and > make use of 'SuppressPropertiesBeanIntrospector'. > More details can be found here: > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114 > http://openwall.com/lists/oss-security/2014/06/15/10 > http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.2/RELEASE-NOTES.txt > https://issues.apache.org/jira/browse/BEANUTILS-463 -- 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)
[jira] [Created] (MYFACES-4034) submitForm() not defined for myfaces.JSF_JS_MODE 'minimal-modern'
Leonardo Uribe created MYFACES-4034: --- Summary: submitForm() not defined for myfaces.JSF_JS_MODE 'minimal-modern' Key: MYFACES-4034 URL: https://issues.apache.org/jira/browse/MYFACES-4034 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.9 Reporter: Leonardo Uribe Taken from stackoverflow: http://stackoverflow.com/questions/34270601/submitform-not-defined-for-myfaces-jsf-js-mode-minimal-modern I tried to set up a simple JSF 2.2 application using MyFaces 2.2.8. Since MyFaces has some context parameters that I never used before, I tried to get familiar with those. So I got to use org.apache.myfaces.JSF_JS_MODE for the first time and ran into problems with h:commandLink. The commandLink is trying to call myfaces.oam.submitForm() which is not defined if I set the mode to minimal-modern. If I set the mode to minimal or normal it works. It looks like a valid bug, worth to take a look. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MYFACES-4035) f:setPropertyActionListener can not assign variable from another Beans with composite component in MyFaces
Leonardo Uribe created MYFACES-4035: --- Summary: f:setPropertyActionListener can not assign variable from another Beans with composite component in MyFaces Key: MYFACES-4035 URL: https://issues.apache.org/jira/browse/MYFACES-4035 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.9 Reporter: Leonardo Uribe Taken from stackoverflow: http://stackoverflow.com/questions/34626568/can-not-assign-variable-from-another-beans-with-composite-component-in-myfaces It is probably that the indirections through complex EL expressions fail when the operation is a set instead a get. Looks like a valid issue, but it is one hard to reproduce and debug. -- This message was sent by Atlassian JIRA (v6.3.4#6332)