tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: Tomcat and SSL
Date Tue, 03 Dec 2002 03:07:06 GMT


On Mon, 2 Dec 2002, Jay Wright wrote:

> Date: Mon, 2 Dec 2002 17:52:14 -0800
> From: Jay Wright <jwright@once.com>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: 'Tomcat Users List' <tomcat-user@jakarta.apache.org>
> Subject: RE: Tomcat and SSL
>
>
> 2 questions below:
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:craigmcc@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>.
>

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:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message