I have one extra question... Asumming one should not switch from https to http for security reasons... How does one handle the situation in which a user should login with a password (that one would like to encrypt so it can't be sniffed)? Should the whole app be run using https? Isn't that too hard on resources?
Does this not switching from https to http also apply when you have apache handling all the ssl comunication? Thanks again in advance. On Tue, 2002-12-03 at 18:37, Alexander Wallace wrote: > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
