Ok, I take back my <whine/>. It seems that they have really made a hash out of the security-constraints. Something like Philippe's implementation is required. Section 12.8.3 requires that only the 'best match' constraints are processed, and those in a 'grant' fashion (i.e. you get the least restrictive privilege of the most restrictive constraints). Now you just need to be a rocket-scientist to figure out how your security-constraints work ;-). So in my example below, a request for /myapp/clients/product1/ will only consider the 'product1' constraint, and ignore the constraint for '/clients/*'. If I had added a security-constraint for '*.jsp', then a request for /myapp/clients/product1/index.jsp would use the 'product1' constraint, and ignore the '*.jsp' constraint. Isn't life going to be fun on the user-list ;-).
This means that RealmBase.findSecurityConstraints is going to have to change to only pass back the 'best-match' constraints. At least this isn't an interface change. The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open.
I don't care much about this problem. Constraint composition is too complex for the real world, and generally container provided auth is just bad to use in real websites. This plus the fact that those changes are brand new (and apparently not tested by Sun's compatibility kit, or Jean François would have done something about it). So this should not impact many people.
I'm ok to change the Realm interface, as there's a RealmBase abstract class. I would believe most realms extend it, so there shouldn't be too much trouble.
We should take ample time to fix this, to make sure this is correct when done :)
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
