7 messages in org.apache.tomcat.usersRE: Tomcat and SSL| From | Sent On | Attachments |
|---|---|---|
| Jay Wright | Dec 2, 2002 10:03 am | |
| Jay Wright | Dec 2, 2002 4:32 pm | |
| Craig R. McClanahan | Dec 2, 2002 5:23 pm | |
| Jay Wright | Dec 2, 2002 5:34 pm | |
| Craig R. McClanahan | Dec 2, 2002 5:43 pm | |
| Jay Wright | Dec 2, 2002 5:51 pm | |
| Craig R. McClanahan | Dec 2, 2002 7:06 pm |
| Subject: | RE: Tomcat and SSL | |
|---|---|---|
| From: | Jay Wright (jwri...@once.com) | |
| Date: | Dec 2, 2002 5:51:52 pm | |
| List: | org.apache.tomcat.users | |
2 questions below:
-----Original Message----- From: Craig R. McClanahan [mailto:crai...@apache.org] Sent: Monday, December 02, 2002 5:43 PM To: Tomcat Users List Subject: RE: Tomcat and SSL
On Mon, 2 Dec 2002, Jay Wright wrote:
Paths specified in <url-pattern> elements are *always* relative to the context path. If you really want every URL in your webapp to be protected, use a URL pattern of "/*" instead of "/a/b/c/*".
Thanks for clarifying, it's beginning to make sense now. As a side note: wouldn't doing a url pattern of "/*" match
all webapps.
No! It is matched against the part of the request URL *after* the context path. That is what "context relative" means.
1. I'm not sure I understand how it would know which context to match against. Couldn't it be /a/b/c or /d or /e/f? There's nothing context specific in <security-constraint>.
and
not just this one? I'll have to extend the relative uri to include some pattern matchable string.
My other question is with <auth-constraint>. It's my current understanding that I can't simply enforce SSL use with a CONFIDENTIAL <transport-gaurantee> in <user-data-constraint>. That I actually need a realm defined, even though I want ALL visitors to be subjected to a SSL redirect if they try to access the webapp. Is there
anyway around this?
I just answered a question on this topic, and gave an example <security-constraint> that required SSL only for context-relative paths that start with "/foo" or "/bar". As long as you do not have an <auth-constraint> element, no login will be required -- only the automatic redirect to SSL if the user accesses one of these URLs.
If you want the transfer to SSL *and* authentication, then you need both an <auth-constraint> and a <transport-guarantee>.
2. When I do this I recieve the following errors:
2002-12-02 17:17:27 Authenticator[/a/b/c]: Security checking request GET /a/b/c/index.jsp 2002-12-02 17:17:27 Authenticator[/a/b/c]: Subject to constraint SecurityConstraint[Gait] 2002-12-02 17:17:27 Authenticator[/a/b/c]: Calling checkUserData() 2002-12-02 17:17:27 Authenticator[/a/b/c]: Failed checkUserData() test
Do I have a misconfiguration elsewhere?