On 28/02/2012 22:27, Shing Wai Chan wrote:
> Hi,
>
> Ron Monzillo has a proposal on configuring DENY semantic.
> The following is the proposal.
I understand where this is coming from.
The rules for combining constraints are already sufficiently complex
that users sometimes have difficulty understanding them. Adding another
variable has the potential to make that problem worse. We therefore need
to be very careful how this is done - if it is done at all.
> To address this issue, we are proposing that a new element be defined for
> use in web.xml that when specified, would cause a deny semantic to be
> applied to uncovered HTTP methods.
I'm not sure a global setting to change the default is the way to go.
What happens when the constraints in the main web.xml are written
assuming one value for the default and the constraints in a fragment are
written assuming a different default? I'm not sure we aren't just
opening ourselves up to more subtle, harder to track down versions of
the problem that already exists.
Is there a way we could add something to the <web-resource-collection>
to indicate that the "uncovered" methods should be denied? Annotations
already have an easy way to change this per annotation.
> To implement this flag it will be necessary for it to effect the processing
> of the @ServletSecurity annotation and the ServletSecurityElement such
> that methods uncovered in these forms will retain their uncovered status
> into constraint combination, after which a deny semantic can be associated
> with any remaining uncovered methods.
I don't like this part of the proposal. It strikes me as too complex.
Would it not be simpler to just change the default empty role semantic
to deny? Of course, that would require the global setting that already
looks problematic...
In summary, I agree that there is a problem but this proposal seems to
be trading one problem for a potentially more complex one. I think it is
worth considering if there is a simpler solution to the problem.
Alternatively, we could treat this purely as a user education issue that
needs a clear explanation of the potential pitfall in the spec and some
guidance on how to avoid it.
Mark