On Mon, 2 Dec 2002, Jay Wright wrote:
> Date: Mon, 2 Dec 2002 17:52:14 -0800 > From: Jay Wright <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > Subject: RE: Tomcat and SSL > > > 2 questions below: > > > -----Original Message----- > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > 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>. > The design goal of web.xml files is that you can deploy the same webapp under *any* context path and it should work, with no changes to any of the context relative paths inside the webapp. The *first* thing Tomcat does is decides which webapp a request is for, based on matching the beginning of the request URI against the context paths of all available contexts. The *second* thing Tomcat does is strips off the context path and matches the remainder against security constraints (and servlet mappings, which work exactly the same way). > > 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 > Four things to review: * Set the debug level to at least 2 to get the most detailed possible messages. I would expect to see additional stuff between "Calling checkUserData()" and "Failed checkUserData() test" that isn't there in your log. * You've got an SSL connector set up and running, right? Otherwise, there's not going to be anywhere to redirect to. * In the <Connector> element for the non-SSL connector, there is an attribute "redirectPort" which is the port number (on the same server) that nonSSL->SSL redirects should go to. It defaults to 8443, and *must* match whatever you've set your SSL connector to. * Check the other log files in $CATALINA_HOME/logs for other possible exceptions that oculd be related. If you're using Tomcat behind Apache, I don't have a clue whether this works at all; my experience is only with Tomcat standalone. Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
