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. 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>. > > Thanks > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
