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