Sometimes reasonable people just disagree. A decision still needs to be
made. That's the job of the Spec Lead.
The platform expert group was very clear that this is a problem worth
solving, and that the proposed solution was acceptable. Several experts
have expressed their opinions to us privately, and I've encouraged them
to make their opinions public here.
Our assessment is that the alternative you've proposed is more complex.
Yes, that's a judgment call. I don't believe that's a judgment based
on misunderstanding your proposal. Yes, I understand that you don't
agree with that judgment. Neither of us is likely to convince the
other that we're right. That's ok.
We have a very limited time left to consider alternatives. In the end,
we're going to do *something*; we're going to address this problem
somehow. If your proposal or some other proposal is technically
complete, addresses the problem, and elicits widespread support,
we can consider whether it's implementable and testable in the time
we have. Having gone through this discussion once where the only
conclusion seemed to be to do nothing, we can't do that again.
So, if there's lots of other Servlet expert group members who think
Greg's proposal is better, now's the time to speak up.
Greg Wilkins wrote on 02/06/2013 10:50 PM:
> Bill,
>
> I have advocated change to security constraints before, but I have not
> put forward this proposal before.
>
> I had thought security constraint changes were off the agenda, but the
> current proposal indicates that it is possible to make significant
> changes, and I simply don't see why either proposal is consider more
> or less significant. Both introduce a new mode to evaluating
> security constraints and both only affect requests that are uncovered.
> One stipulates deny semantics and the other fall through semantics.
> Complexity wise they are much of a muchness and I think it is a
> straw man to deny one on the grounds of complexity.
>
> Furthermore, it is a bit rough to post a message very late in the
> process saying that an already dismissed proposal is being forced
> through and then criticise an amendment to that proposal for being too
> late in the process. Can we give both proposals a bit of time for
> others in the EG to make considered replies.
>
>
> regards
>
>
>
>
>
> On 6 February 2013 15:28, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>> Hi Greg. I'm not aware of all the background here but my understanding
>> is that the Servlet expert group has seen this proposal of yours before.
>> Your proposal is a different matching algorithm to determine which
>> security constraints apply to which http requests. I understand that
>> you believe it is more intuitive, but I'm not seeing any support for
>> this different model from other members of the Servlet expert group.
>>
>> In any event, it's getting pretty late in this release to consider
>> such a significant change. As Ron has described, our proposed change
>> does not change the matching algorithm at all, and so is a somewhat
>> simpler change to introduce at this late date.
>>
>> Given that the platform expert group widely support our proposed change,
>> and that there's no support even in the Servlet expert group for your
>> change, I think we need to go ahead with our change as proposed.
>>
>> If you still think a more significant change is desirable, feel free to
>> bring it up again for Java EE 8.
>>
>> Thanks.
>>
>>
>> Greg Wilkins wrote on 02/04/13 16:21:
>>> On 5 February 2013 02:06, Ron Monzillo <ron.monzillo_at_oracle.com> wrote:
>>>>
>>>> . The Servlet security model is a path model designed to secure the paths
>>>> used to access Servlets.
>>>> As such, it is analogous and closely aligned with the Servlet mapping model.
>>>> In both, the
>>>> best matching algorithm is based only on url-pattern.
>>>
>>> And that is exactly the problem. Security constraints have 2 matching
>>> criteria that can be specified: url and method, but only url is
>>> actually used and the method is not a selector but a modifier of
>>> behaviour.
>>>
>>> This is confusing for developers and results in sets of constraints
>>> that do not act as expected. The current proposal does not fix the
>>> confusion, but instead just adds a mode that is a little bit less
>>> likely for a mistake to have adverse effects. But I would
>>> say that any change to the security model that does not fix the cause
>>> of the problem, but just moderates the effect is just a band-aid fix.
>>>
>>> You have made the association between constraint matching and servlet
>>> matching. In reality the analogy should be to filter matching as
>>> filters have both a url and a dispatch type that they are matched by.
>>> With filters, if the path matches a request but the dispatcher type
>>> does not, then that filter simply does not affect that request at all.
>>>
>>> The current security model is analogous to saying that a filter at
>>> ERROR:/foo/bar would prevent a filter at REQUEST:/foo/* from matching
>>> a normal request to /foo/bar. That is the fundamental confusions and
>>> changing the unexpected result from Allow to Deny is just a band aid.
>>> If we are to change the security model, let's fix it rather than
>>> patch it.
>>>
>>>
>>>> . The proposal does not seek to create two models or even two modes.
>>>
>>> But it does. Depending on the setting of a boolean a set of security
>>> constraints will be interpreted differently. Saying that the
>>> difference is only small does not mean that it is not a mode.
>>>
>>>> It's
>>>> pupose is to
>>>> provide a simple way to cause there to be an explicit protection
>>>> specification for all HTTP methods
>>>> at all constrained url-patterns. Applications that follow the
>>>> recommendations for
>>>> defining security constraints, (e.g.,
>>>> http://docs.oracle.com/javaee/6/tutorial/doc/gmmku.html)
>>>> will feature no uncovered methods, and WILL BEHAVE EXACTLY THE SAME
>>>> INDEPENDENT OF THE
>>>> SETTING OF THE PROPOSED FLAG.
>>>
>>> And that holds for my proposal as well. If there are no uncovered
>>> requests, then the provisions of neither proposal come into play.
>>> Both proposals only deal with what happens if there are uncovered
>>> methods. The current proposal is to change the unexpected behaviour
>>> from Allow to Deny but does not deal with the fundamental confusion.
>>>
>>> My proposal is to allow uncovered requests to sensible fall through to
>>> the next most specific matching constraint in a way that is logical
>>> and simple for developers to understand. Indeed in a way that most
>>> developers already expect it to occur.
>>>
>>> In either case, I do not believe it is wise for us to advocate that a
>>> deployer simply switch the boolean on a webapplication and not inspect
>>> the actual security constraints and evaluate their behaviour. In
>>> both cases, it may be that a deployer might have to add a few
>>> constraints to web.xml after switching the boolean to true to correct
>>> issues within the constraints defined within jars/fragments.
>>>
>>> Please don't impose another band-aid fix that just adds more
>>> complexity and does not fix the fundamental problem.
>>>
>>> regards
>>>
>>>
>>
>
>
>