Return-Path: Delivered-To: apmail-shale-issues-archive@locus.apache.org Received: (qmail 43961 invoked from network); 18 Sep 2006 10:09:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 18 Sep 2006 10:09:49 -0000 Received: (qmail 72220 invoked by uid 500); 18 Sep 2006 10:09:49 -0000 Delivered-To: apmail-shale-issues-archive@shale.apache.org Received: (qmail 72202 invoked by uid 500); 18 Sep 2006 10:09:49 -0000 Mailing-List: contact issues-help@shale.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@shale.apache.org Delivered-To: mailing list issues@shale.apache.org Received: (qmail 72192 invoked by uid 99); 18 Sep 2006 10:09:49 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Sep 2006 03:09:49 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Sep 2006 03:09:46 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id A0ABD7142F2 for ; Mon, 18 Sep 2006 10:05:31 +0000 (GMT) Message-ID: <16144814.1158573931633.JavaMail.jira@brutus> Date: Mon, 18 Sep 2006 03:05:31 -0700 (PDT) From: "Mike Meessen (JIRA)" To: issues@shale.apache.org Subject: [jira] Created: (SHALE-287) Faulty behavior of the "token" component with Apache MyFaces >1.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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