[ 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
