11 messages in org.apache.tomcat.usersRe: Filters don't affect request disp...| From | Sent On | Attachments |
|---|---|---|
| Alexander Wallace | Dec 2, 2002 4:41 pm | |
| Craig R. McClanahan | Dec 2, 2002 5:31 pm | |
| Bill Barker | Dec 2, 2002 11:49 pm | |
| Jacob Kjome | Dec 3, 2002 5:46 am | |
| Alexander Wallace | Dec 3, 2002 8:20 am | |
| Craig R. McClanahan | Dec 3, 2002 9:12 am | |
| Craig R. McClanahan | Dec 3, 2002 9:20 am | |
| Alexander Wallace | Dec 3, 2002 9:36 am | |
| Alexander Wallace | Dec 3, 2002 12:42 pm | |
| Craig R. McClanahan | Dec 3, 2002 9:41 pm | |
| Alexander Wallace | Dec 4, 2002 8:20 am |
| Subject: | Re: Filters don't affect request dispatcher forward | |
|---|---|---|
| From: | Craig R. McClanahan (crai...@apache.org) | |
| Date: | Dec 3, 2002 9:20:36 am | |
| List: | org.apache.tomcat.users | |
On 3 Dec 2002, Alexander Wallace wrote:
Date: 03 Dec 2002 10:21:19 -0600 From: Alexander Wallace <tomc...@rwsoft-online.com> Reply-To: Tomcat Users List <tomc...@jakarta.apache.org> To: Tomcat Users List <tomc...@jakarta.apache.org> 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