tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Francois Arcand <>
Subject Re: [5] Authentication for Overlapping Constraints
Date Thu, 24 Jul 2003 13:20:00 GMT

Bill Barker wrote:

>Tomcat doesn't adhere to the (new) requirements in the 2.4 Servlet-Spec for
>handling the case of Overlapping Constraints:
><spec-quote version="2.4 pfd3" section="12.8.1">
>When a url-pattern and http-method pair occurs in multiple security
>constraints, the
>applicable constraints (on the pattern and method) are defined by combining
>individual constraints.
>I see two ways to address this, but can't pick a clear favorite (hence
>asking for comments :).
>1)  Add a method 'List getSecurityConstraints(HttpRequest req, Context ctx)'
>to Realm, and have AuthenticatorBase loop through them.
>2) Have RealmBase create it's own special SecurityConstraint that is the
>intersection of all of the overlapping constraints, and leave
>AuthenticatorBase alone.
>Case 1 has the advantage of being relatively clean from a coding standpoint.
>Case 2 would probably require adding a 'void intersect(SecurityContraint
>sc)' method to the SecurityConstraint class to enable it to construct the
>correct permissions (and this looks like it would be a non-trivial method to
In Realm, we already have:

>     /**
>      * Return the SecurityConstraint configured to guard the request 
> URI for
>      * this request, or <code>null</code> if there is no such constraint.
>      *
>      * @param request Request we are processing
>      */
>     public SecurityConstraint findSecurityConstraint(HttpRequest request,
>                                                      Context context);

Can we modify that method to properly handle the spec?

-- Jeanfrancois

>This message is intended only for the use of the person(s) listed above as the intended
recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL.  If you are
not an intended recipient, you may not read, copy, or distribute this message or any attachment.
If you received this communication in error, please notify us immediately by e-mail and then
delete all copies of this message and any attachments.
>In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet
is not secure. Do not send confidential or sensitive information, such as social security
numbers, account numbers, personal identification numbers and passwords, to us via ordinary
(unencrypted) e-mail.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message