[ 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
