You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shale.apache.org by "Mike Meessen (JIRA)" <ji...@apache.org> on 2006/09/18 12:05:31 UTC
[jira] Created: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Faulty behavior of the "token" component with Apache MyFaces >1.1.1
-------------------------------------------------------------------
Key: SHALE-287
URL: http://issues.apache.org/struts/browse/SHALE-287
Project: Shale
Issue Type: Bug
Components: Core
Affects Versions: 1.0.3, 1.0.4-SNAPSHOT
Environment: OS: Microsoft Windows XP SP2
Servlet Container: jakarta-tomcat-5.5.9
Reporter: Mike Meessen
This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
[Quote]
This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
[/Quote]
So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
Steps to reproduce the issue:
* Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
* As long as you submit the form correctly, everyting works fine.
* Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
* Discard the warning and go on resending the same HTTP request.
* Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
**** This is the part where the behavior changes according to what MyFaces version is used:
With MyFaces 1.1.1
--------------------------
* Resubmit the form correctly (using the submit button).
==> The workflow goes on and the form is correctly submitted.
With MyFaces 1.1.2 and above
-----------------------------------------
* Resubmit the form correctly (using the submit button).
==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
I attached a sample project which demoes the issue.
Regards,
Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=comments#action_38615 ]
Craig McClanahan commented on SHALE-287:
----------------------------------------
OK, I can now see what I think is going on, and can reproduce your reload scenario using the shale-test-core.war example. Here's what I did:
* Start with a fresh session
* Navigate to the "Token Processor"
* Type in a value on Page 1 and click "Submit"
* Observe that Page 2 is now displayed
* Press F5 to try a refresh
* Get the warning about doing a POST again, click OK
* Get an error message about "invalid resubmit of the same form".
Note that page *1* is shown here, not page *2* ... because it was
indeed a duplicate submit of page 1.
My belief is that this is, in fact, the behavior we want to see ... the reload was indeed a resubmit of the content for page 1, and we want to not process it. The challenge is, what happens next? And that question is equally applicable if (from page 2) I had used the back arrow to go back to page 1, then clicked it's submit button again.
It seems to me that the application needs to provide an "escape valve" of some sort, typically in the form of a cancel button with its immediate attribute set to true, that aborts the current workflow and gets the application back to a known state. I don't see an approach that will let the framework recover gracefully from this scenario within a current workflow -- the framework is not going to have any knowledge of what state information might have been mutated, or where to go next without resubmitting. Do you have any suggestions?
At the moment, I'm leaning towards considering the current functionality as "works as designed."
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: shale-test-core.war, ShaleIssueDemo.war, ShaleIssueDemo.zip
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=all ]
Craig McClanahan resolved SHALE-287.
------------------------------------
Resolution: Not A Problem
Based on the extended discussion, come to the conclusion that the current functionality works as designed. The application has opportunities to provide an "escape hatch" by using command components with immediate="true", which will fire before validation has had a chance to kick in.
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: shale-test-core.war, ShaleIssueDemo.war, ShaleIssueDemo.zip, Token.java.diff
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=all ]
Craig McClanahan reassigned SHALE-287:
--------------------------------------
Assignee: Craig McClanahan
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: ShaleIssueDemo.zip
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Mike Meessen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=all ]
Mike Meessen updated SHALE-287:
-------------------------------
Affects Version/s: (was: 1.0.4-SNAPSHOT)
(was: 1.0.3)
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Attachments: ShaleIssueDemo.zip
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Mike Meessen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=comments#action_38645 ]
Mike Meessen commented on SHALE-287:
------------------------------------
Hi Craig,
Thanks for the quick reply! I understand your point of view for this and I am going to adapt my application to provide those "escape hatches" where possible.
I just wanted to mention that such a form resubmission could also happen if a user clicks the same button twice (because the internet connection or the server are slow).
Regards,
Mike Meessen
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: shale-test-core.war, ShaleIssueDemo.war, ShaleIssueDemo.zip, Token.java.diff
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Mike Meessen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=comments#action_38611 ]
Mike Meessen commented on SHALE-287:
------------------------------------
Hi Craig,
I tested your attachement (shale-test-core.war). Indeed, this runs well and behaves as expected.
However, I replaced all the libraries I was using in my test project with the ones you included in your war, I moved the token tag to the end of the <h:form> declaration too, but the problem still persists in my test case.
I don't use any inputText though, but simply the refresh button of the browser. I don't think this behavior is expected, since with MyFaces 1.1.1 it works...
I included the mofidied test project as ShaleIssueDemo.war. I hope it will help you finding the issue.
Regards,
Mike Meessen
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: shale-test-core.war, ShaleIssueDemo.war, ShaleIssueDemo.zip
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Mike Meessen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=all ]
Mike Meessen updated SHALE-287:
-------------------------------
Description:
This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
[Quote]
This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
[/Quote]
So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
Steps to reproduce the issue:
* Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
* As long as you submit the form correctly, everyting works fine.
* Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
* Discard the warning and go on resending the same HTTP request.
* Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
**** This is the part where the behavior changes according to what MyFaces version is used:
With MyFaces 1.1.1
--------------------------
* Resubmit the form correctly (using the submit button).
==> The workflow goes on and the form is correctly submitted.
With MyFaces 1.1.2 and above
-----------------------------------------
* Resubmit the form correctly (using the submit button).
==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
I attached a sample project which demoes the issue.
-- EDIT:
I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
Regards,
Mike
was:
This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
[Quote]
This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
[/Quote]
So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
Steps to reproduce the issue:
* Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
* As long as you submit the form correctly, everyting works fine.
* Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
* Discard the warning and go on resending the same HTTP request.
* Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
**** This is the part where the behavior changes according to what MyFaces version is used:
With MyFaces 1.1.1
--------------------------
* Resubmit the form correctly (using the submit button).
==> The workflow goes on and the form is correctly submitted.
With MyFaces 1.1.2 and above
-----------------------------------------
* Resubmit the form correctly (using the submit button).
==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
I attached a sample project which demoes the issue.
Regards,
Mike
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.4-SNAPSHOT, 1.0.3
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Attachments: ShaleIssueDemo.zip
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=all ]
Craig McClanahan updated SHALE-287:
-----------------------------------
Attachment: shale-test-core.war
I've completed a test app which (I believe) illustrates that the current trunk code of Shale operates as expected. In particular, you should expect the following behavior when using the token component:
* If you submit invalid data (per validator rules) and get back the
same page with error messages, you should be able to correct
the errors and submit the form (exactly once with correct data).
* If you submit the form successfully, and then use the browser
back button and then submit the same form again, you should
get the "double submit" error message.
The attached "shale-test-core.war" application uses the current version of MyFaces (1.1.4), and (as far as I can tell) operates correctly in all use cases. PLEASE try this application yourself and see if you can break it. The comments on the app's pages should be pretty self explanatory.
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: shale-test-core.war, ShaleIssueDemo.zip
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "john book (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=comments#action_38891 ]
john book commented on SHALE-287:
---------------------------------
http://www.chatarea.com/freecisco21.f81887-1
http://www.chatarea.com/freecisco21.f81887
http://www.chatarea.com/freecisco21.f81887-2
http://www.chatarea.com/freecisco21.f81887-3
http://www.chatarea.com/freecisco21.f81887-4
http://www.chatarea.com/freecisco21.m3876846
http://www.chatarea.com/freecisco21.m3876845
http://www.chatarea.com/freecisco21.m3876844
http://www.chatarea.com/freecisco21.m3876843
http://www.chatarea.com/freecisco21.m3876842
http://www.chatarea.com/freecisco21.m3876841
http://www.chatarea.com/freecisco21.m3876840
http://www.chatarea.com/freecisco21.m3876839
http://www.chatarea.com/freecisco21.m3876838
http://www.chatarea.com/freecisco21.m3876837
http://www.chatarea.com/freecisco21.m3876836
http://www.chatarea.com/freecisco21.m3876834
http://www.chatarea.com/freecisco21.m3876832
http://www.chatarea.com/freecisco21.m3876831
http://www.chatarea.com/freecisco21.m3876830
http://www.chatarea.com/freecisco21.m3876828
http://www.chatarea.com/freecisco21.m3876826
http://www.chatarea.com/freecisco21.m3876824
http://www.chatarea.com/freecisco21.m3876823
http://www.chatarea.com/freecisco21.m3876822
http://www.chatarea.com/freecisco21.m3876820
http://www.chatarea.com/freecisco21.m3876819
http://www.chatarea.com/freecisco21.m3876818
http://www.chatarea.com/freecisco21.m3876817
http://www.chatarea.com/freecisco21.m3876816
http://www.chatarea.com/freecisco21.m3876815
http://www.chatarea.com/freecisco21.m3876813
http://www.chatarea.com/freecisco21.m3876812
http://www.chatarea.com/freecisco21.m3876811
http://www.chatarea.com/freecisco21.m3876810
http://www.chatarea.com/freecisco21.m3876809
http://www.chatarea.com/freecisco21.m3876808
http://www.chatarea.com/freecisco21.m3876806
http://www.chatarea.com/freecisco21.m3876805
http://www.chatarea.com/freecisco21.m3876804
http://www.chatarea.com/freecisco21.m3876801
http://www.chatarea.com/freecisco21.m3876800
http://www.chatarea.com/freecisco21.m3876799
http://www.chatarea.com/freecisco21.m3876797
http://www.chatarea.com/freecisco21.m3876796
http://www.chatarea.com/freecisco21.m3876794
http://www.chatarea.com/freecisco21.m3876793
http://www.chatarea.com/freecisco21.m3876792
http://www.chatarea.com/freecisco21.m3876790
http://www.chatarea.com/freecisco21.m3876789
http://www.chatarea.com/freecisco21.m3876788
http://www.chatarea.com/freecisco21.m3876787
http://www.chatarea.com/freecisco21.m3876786
http://www.chatarea.com/freecisco21.m3876785
http://www.chatarea.com/freecisco21.m3876782
http://www.chatarea.com/freecisco21.m3876781
http://www.chatarea.com/freecisco21.m3876780
http://www.chatarea.com/freecisco21.m3876779
http://www.chatarea.com/freecisco21.m3876778
http://www.chatarea.com/freecisco21.m3876776
http://www.chatarea.com/freecisco21.m3876775
http://www.chatarea.com/freecisco21.m3876774
http://www.chatarea.com/freecisco21.m3876773
http://www.chatarea.com/freecisco21.m3876771
http://www.chatarea.com/freecisco21.m3876770
http://www.chatarea.com/freecisco21.m3876769
http://www.chatarea.com/freecisco21.m3876768
http://www.chatarea.com/freecisco21.m3876767
http://www.chatarea.com/freecisco21.m3876766
http://www.chatarea.com/freecisco21.m3876765
http://www.chatarea.com/freecisco21.m3876764
http://www.chatarea.com/freecisco21.m3876763
http://www.chatarea.com/freecisco21.m3876762
http://www.chatarea.com/freecisco21.m3876761
http://www.chatarea.com/freecisco21.m3876759
http://www.chatarea.com/freecisco21.m3876758
http://www.chatarea.com/freecisco21.m3876757
http://www.chatarea.com/freecisco21.m3876756
http://www.chatarea.com/freecisco21.m3876755
http://www.chatarea.com/freecisco21.m3876754
http://www.chatarea.com/freecisco21.m3876753
http://www.chatarea.com/freecisco21.m3876752
http://www.chatarea.com/freecisco21.m3876751
http://www.chatarea.com/freecisco21.m3876750
http://www.chatarea.com/freecisco21.m3876749
http://www.chatarea.com/freecisco21.m3876748
http://www.chatarea.com/freecisco21.m3876747
http://www.chatarea.com/freecisco21.m3876746
http://www.chatarea.com/freecisco21.m3876745
http://www.chatarea.com/freecisco21.m3876740
http://www.chatarea.com/freecisco21.m3876739
http://www.chatarea.com/freecisco21.m3876738
http://www.chatarea.com/freecisco21.m3876737
http://www.chatarea.com/freecisco21.m3876736
http://www.chatarea.com/freecisco21.m3876735
http://www.chatarea.com/freecisco21.m3876734
http://www.chatarea.com/freecisco21.m3876733
http://www.chatarea.com/freecisco21.m3876732
http://www.chatarea.com/freecisco21.m3876729
http://www.chatarea.com/freecisco21.m3876727
http://www.chatarea.com/freecisco21.m3876726
http://www.chatarea.com/freecisco21.m3876724
http://www.chatarea.com/freecisco21.m3876722
http://www.chatarea.com/freecisco21.m3876720
http://www.chatarea.com/freecisco21.m3876719
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: shale-test-core.war, ShaleIssueDemo.war, ShaleIssueDemo.zip, Token.java.diff
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Mike Meessen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=all ]
Mike Meessen updated SHALE-287:
-------------------------------
Attachment: ShaleIssueDemo.war
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: shale-test-core.war, ShaleIssueDemo.war, ShaleIssueDemo.zip
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=all ]
Craig McClanahan updated SHALE-287:
-----------------------------------
Comment: was deleted
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: shale-test-core.war, ShaleIssueDemo.war, ShaleIssueDemo.zip, Token.java.diff
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=comments#action_38606 ]
Craig McClanahan commented on SHALE-287:
----------------------------------------
> Hi! I've downloaded the Token source code from the repository and make myself a test project.
> I have the following page.jsp with source code
Adrian,
Just to verify things, did you build all of Shale from the current trunk source code, and use it in your test, or were you using some modules from the 1.0.3 release? This matters, because 1.0.3 did have the bug you describe, but it was subsequently fixed. So, building from the trunk source (or using a recent nightly build) should *not* have this particular error.
To verify this, I just checked in a new test application (shale-test-core) that verifies proper behavior. Among other things, it tries the scenario you describe ... submit a form (with the token) with input data that fails validation, and then resubmits the form with valid data.
One other important note -- for the <s:token> component to work correctly, it must be the *last* input component inside the form. This is because it needs to detect whether any of the other components have fired a validation error, in order to know whether or not to reset the token. Your test case has the token component first instead of last.
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: ShaleIssueDemo.zip
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Mike Meessen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=comments#action_38618 ]
Mike Meessen commented on SHALE-287:
------------------------------------
Hi Craig,
I just spent a day of work trying to understand, reproduce and find a patch for the described issue.
At first a "management summary", details follow.
If the user supplied an invalid token as consequence of for example using the back button, we have to remove the token attribute to avoid being stuck with the old (invalid) token forever.
Details:
* The fact that myfaces prior to v1.1.2 behaves differently then v1.1.2 and above seems to be a very little bug in the old myfaces implementation concerning UIInput validation. As a conclusion, I focused on shale and the token tag, trying to achive the behavior I experienced with myfaces 1.1.1.
* In my opinion, two phenomenes appear at the same time here:
1) In certain cases, the token value should be regenerated to avoid the application to get stuck.
2) In cases where the token detects that the submission it gets has not been initiated from the last served viewId (thus, the user clicked the back button once or more), we'd need a mechanism to redirect to the last served viewId, providing a fresh representation of that viewId.
At first, I tried to fix point 1.
The token tag operates as standard UIComponent with standard jsf component validation to "manipulate" faces behavior. If a valid token gets submitted, the application phases go through as normal:
* restoreView
* applyRequestValues
* processValidations <= That's where the token tests it's validity
* updateModelValues
* invokeApplication
==> renderResponse
But, what if the submitted token value is invalid? It would look like this:
* restoreView
* applyRequestValues
* processValidations <= That's where the token tests it's validity
==> renderResponse
Taking things a bit further, I noticed that since the "Apply Request Values" phase already wrote the new (invalid) token value to the token UIComponent, this (invalid) value will be used for rendering the response... So as a conclusion, the response will be generated with the submitted (invalid) token value.
To avoid this, I simply reset the token value (I removed the TOKEN_ATTRIBUTE_KEY from the UIComponent's attributes map) if the validation fails. Then, in the render response phase, the token tests it's value and generates a new one.
The result is that I:
* successfully told JSF that a validation error occured, so I bypassed any model updates and application invokes (the primary goal of the token component)
* delivered a fresh page to the user, displaying the latest valid state of the viewId
* generated a new token, so the user will be able to go on from the served page.
The only inconvenience I see applying this method is the following:
-------------------------------------------------------------------------------------------
When a token is generated, it is put in a map in session scope called "ShaleConstants.TOKENS".
When a valid token is submitted, the TokenProcessor.verify() method removes it from that map. This is the right mechanism, since this token has now been consumed and should never be consumed again.
BUT: in my case, where a token is re-generated due to an invalid request, the old token (which would have been submitted by a valid request) will stay in the "ShaleConstants.TOKENS" map in the session scope. With the current architecture, I think I have no chance to know what would have been the correct token in order to remove it from that map.
I have been unable to find a *simple* way around that without having to change this mechanism...
I included a patchfile for shale(-core) which applies my one-line patch...
------------
As I mentioned before, this only solves the first phenomene...
To solve the second one (which would be "serve the right viewId even if an old page gets submitted"), I think the only simple way would be:
* shale must keep in mind which was the last served viewId (page)
* whenever a HTTP POST request comes from another viewId as the one the user was supposed to have in front of him, the last served viewId is re-served (with a re-generated token value). That would be achieved by a redirect in the validation phase of the token... I know this is not really pretty but I think it would solve any double-submit, back-button, etc. problems we all are struggling with.
-----------
I hope this has been well described, it really isn't easy ;-)
Looking forward to hearing from you!!
Regards,
Mike Meessen
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: shale-test-core.war, ShaleIssueDemo.war, ShaleIssueDemo.zip, Token.java.diff
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Adrian Mitev (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=comments#action_38602 ]
Adrian Mitev commented on SHALE-287:
------------------------------------
Hi! I've downloaded the Token source code from the repository and make myself a test project. I have the following:
page.jsp with source code:
<h:form id="helloForm">
<s:token id="token" messageDetail="double submit" messageSummary="double submit" />
<h:messages />
<t:inputText required="true" value="#{GetNameBean.userName}">
<f:validateLength minimum="2" maximum="20"/>
</t:inputText>
<t:commandButton id="submit" action="sayhello" value="Say Hello" />
</h:form>
When i submit the page without any value inputted i get validation error and the page is redisplayed. I input value in the input field and submit the form again, then i got error message from the token - "double submit".
I've debugged a little bit and saw that when validation error occurred and the page is redisplayed the token value was not changed (no new token is generated):
Check the class: org.apache.shale.component.Token, method: public String getToken() the code
if (value != null) {
return value;
}
This condition is always true after the page is rendered for the first time.
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: ShaleIssueDemo.zip
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Mike Meessen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=all ]
Mike Meessen updated SHALE-287:
-------------------------------
Attachment: ShaleIssueDemo.zip
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.4-SNAPSHOT, 1.0.3
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Attachments: ShaleIssueDemo.zip
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Mike Meessen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=all ]
Mike Meessen updated SHALE-287:
-------------------------------
Attachment: Token.java.diff
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: shale-test-core.war, ShaleIssueDemo.war, ShaleIssueDemo.zip, Token.java.diff
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-287) Faulty behavior of the "token"
component with Apache MyFaces >1.1.1
Posted by "Craig McClanahan (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/struts/browse/SHALE-287?page=comments#action_38644 ]
Craig McClanahan commented on SHALE-287:
----------------------------------------
Mike,
Thanks for taking the time to dive into this ... it has indeed been well described. But, unfortunately, I want to go back to your basic premise for a moment ... the assumption that the framework should provide a mechanism to recover from the rePOSt (or back button then resubmit) scenario at all. I'm coming at this from two separate directions:
* It is trivially simple for an application to provide an "escape hatch" when the
user screws up ... create a "Cancel" button with immediate="true", and this
action will get processed *before* Process Validations phase, and therefore
will bypass the check performed by the Token component.
* I do not see any reasonable way for the framework to predict what state changes
in the model will be needed to get back into synchronization with a workflow.
Indeed, the user violated HTTP spec requirements in the first place by resubmitting
a request that is, by definition, allowed to mutate server side state. I feel *really*
uncomfortable about trying to lead developers into believing that this sort of
behavior should be not only condoned, but supported.
Interestingly, Struts has had very similar functionality (with the same sort of restriction on what happens when you encounter a resubmit) for six years now, and it hasn't seemed to stop people from adopting it :-).
I strongly encourage you to approach this problem by:
* Providing escape hatches like a Cancel button (or even a special button that
knows how to recover for *your* application) with immediate="true", for which
JSF already provides all the support you need.
* As you discover cases where users tend to use back buttons, look for ways
to add extra navigation links within the UI so they can accomplish their goal
without using the browser navigation controls.
Craig
PS: I'm not going to spend any time investigating why MyFaces 1.1.1 works differently ... that release had so many other issues that users are very well served by moving to 1.1.4 or later.
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> -------------------------------------------------------------------
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
> Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: shale-test-core.war, ShaleIssueDemo.war, ShaleIssueDemo.zip, Token.java.diff
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The core refers to the JSF 1.1 implementation as specified by JSR-127. It has passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic gets invoked).
> **** This is the part where the behavior changes according to what MyFaces version is used:
> With MyFaces 1.1.1
> --------------------------
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -----------------------------------------
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't make a difference since I'm using HTTP POST just as the javascript would do, but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira