shale-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SHALE-287) Faulty behavior of the "token" component with Apache MyFaces >1.1.1
Date Tue, 07 Nov 2006 06:05:57 GMT
    [ 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

        

Mime
View raw message