You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Bill Barker <wb...@wilshire.com> on 2003/07/24 06:39:00 UTC
[5] Authentication for Overlapping Constraints
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?
Re: [5] Authentication for Overlapping Constraints
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Jean-Francois Arcand" <jf...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, July 24, 2003 6:20 AM
Subject: Re: [5] Authentication for Overlapping Constraints
>
>
> 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
> >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?
> >
> 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?
That is basically my case 2.
I'm leaning in the direction of case 1 at the moment. It is easier to
implement, much easier to optimize, and for a major-version release we
should be able to adapt the Catalina API to do what the spec requires. A
custom Realm that doesn't extend RealmBase needs to be re-done for 5.0 in
either case to be complient.
>
> -- 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: tomcat-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [5] Authentication for Overlapping Constraints
Posted by Jean-Francois Arcand <jf...@apache.org>.
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
>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?
>
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: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.5] New tag tomorrow ?
Posted by Jean-Francois Arcand <jf...@apache.org>.
+1
Remy Maucherat wrote:
> To be able to reach beta quality around the end of this month, a new
> milestone will need to be released at the end of this week (and more
> generally, I think a one milestone per week schedule can't hurt when
> trying to go to beta - even if we end up missing the deadline ;-) ).
>
> As usual, I'll populate the changelog. I'll also try to add some docs
> content.
>
> Comments ?
>
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.5] New tag tomorrow ?
Posted by Tim Funk <fu...@joedog.org>.
Sounds good to me. I have some small docs fixes I'll push soon.
-Tim
Remy Maucherat wrote:
> To be able to reach beta quality around the end of this month, a new
> milestone will need to be released at the end of this week (and more
> generally, I think a one milestone per week schedule can't hurt when
> trying to go to beta - even if we end up missing the deadline ;-) ).
>
> As usual, I'll populate the changelog. I'll also try to add some docs
> content.
>
> Comments ?
>
> Remy
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.5] New tag tomorrow ?
Posted by Amy Roh <am...@yahoo.com>.
+1
Amy
--- Remy Maucherat <re...@apache.org> wrote:
> To be able to reach beta quality around the end of
> this month, a new
> milestone will need to be released at the end of
> this week (and more
> generally, I think a one milestone per week schedule
> can't hurt when
> trying to go to beta - even if we end up missing the
> deadline ;-) ).
>
> As usual, I'll populate the changelog. I'll also try
> to add some docs
> content.
>
> Comments ?
>
> Remy
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tomcat-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
[5.0.5] New tag tomorrow ?
Posted by Remy Maucherat <re...@apache.org>.
To be able to reach beta quality around the end of this month, a new
milestone will need to be released at the end of this week (and more
generally, I think a one milestone per week schedule can't hurt when
trying to go to beta - even if we end up missing the deadline ;-) ).
As usual, I'll populate the changelog. I'll also try to add some docs
content.
Comments ?
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5] Authentication for Overlapping Constraints
Posted by Remy Maucherat <re...@apache.org>.
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
> 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?
1) seems better from your description. It could be a good idea to
confirm that the spec change will still be in the final version.
I'd like to add that a lot of this code is unoptimized (it abuses
substring, whereas it could likely use region matching), so maybe it
could be a good opportunity to improve it (along with BASIC auth handling).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org