Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 13365 invoked from network); 3 Dec 2002 17:21:26 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Dec 2002 17:21:26 -0000 Received: (qmail 6467 invoked by uid 97); 3 Dec 2002 17:22:10 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 6451 invoked by uid 97); 3 Dec 2002 17:22:10 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 6439 invoked by uid 98); 3 Dec 2002 17:22:09 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Tue, 3 Dec 2002 09:20:58 -0800 (PST) From: "Craig R. McClanahan" To: Tomcat Users List Subject: Re: Filters don't affect request dispatcher forward In-Reply-To: <1038932479.15833.2.camel@debofo1> Message-ID: <20021203091341.U16000-100000@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 3 Dec 2002, Alexander Wallace wrote: > Date: 03 Dec 2002 10:21:19 -0600 > From: Alexander Wallace > Reply-To: Tomcat Users List > To: Tomcat Users List > Subject: Re: Filters don't affect request dispatcher forward > > Hey I love that! Thanks, let me try it! > > Now, with this solution, I figure i can't fore stuff that doesn't match > the "to be secured" pattern to go over http and not https if it is > requested, right? I still can live with that, but it would sure be > cool.. > I'm not sure what you're really asking, but ... If you declare a security constraint with a transport guarantee, any URL that matches the specified pattern(s) can *only* be accessed via SSL. Any URL that does not match the pattern can be accessed over *either* SSL or non-SSL. One additional note -- web applications that allow a user to switch from SSL back to non-SSL on the same session are broken. What you've just done is allowed anyone snooping the network to swipe the session id and impersonate your user (for example, click the "buy" button again using the credit card number that was entered on a secure page). You should program your apps that, once a user switches from non-SSL to SSL, you never again accept a non-SSL request for that same session id. If the user needs to go back (for example, after checking out of an ecommerce site you want to buy some more stuff), start a new session first (and clear the confidential data you might have captured). > Thanks! Craig -- To unsubscribe, e-mail: For additional commands, e-mail: