Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 83556 invoked from network); 1 Nov 2002 03:18:20 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 1 Nov 2002 03:18:20 -0000 Received: (qmail 28223 invoked by uid 97); 1 Nov 2002 03:19:16 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 28182 invoked by uid 97); 1 Nov 2002 03:19:15 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 28167 invoked by uid 50); 1 Nov 2002 03:19:14 -0000 Date: 1 Nov 2002 03:19:14 -0000 Message-ID: <20021101031914.28166.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: tomcat-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 6279] - Resubmit to j_security_check mistakenly fetches a page of that name X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6279 Resubmit to j_security_check mistakenly fetches a page of that name ------- Additional Comments From rhoegg@isisnetworks.net 2002-11-01 03:19 ------- This bug is still around in 4.1.12. Brian: The code you posted and the modification you posted afterward are difficult to understand. It is usually standard practice to post patches in unified diff format (diff -u). My understanding of the problem is that: 1. We want FormAuthenticator to mirror BasicAuthenticator as closely as possible from the user's perspective. 2. In BASIC authentication, when a user successfully authenticates and presses the "back" button, the user is returned to the page she was on before attempting to access a secured resource. If the attempt to access the secured resource is the very first page visited after opening a browser, then the "Back" button is unavailable. Number 2 is not reproducible using FormAuthenticator because an extra request is generated (the request for the login page). Therefore we must decide on a desired behavior for this scenario. Any takers? -- To unsubscribe, e-mail: For additional commands, e-mail: