[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)
