Bill Barker wrote:
In Realm, we already have: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 the individual constraints. </spec-quote>
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 implement).
Comments/Opinions/Flames?
/**
* 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
