Ok, thankyou for the advice, I will do that then. What i was trying to do is actually what you are telling me i shouldn't.
Again, thanks! On Tue, 2002-12-03 at 11:20, Craig R. McClanahan wrote: > > > On 3 Dec 2002, Alexander Wallace wrote: > > > Date: 03 Dec 2002 10:21:19 -0600 > > From: Alexander Wallace <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > To: Tomcat Users List <[EMAIL PROTECTED]> > > 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: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
