On 8 February 2013 17:44, Greg Wilkins <gregw_at_intalio.com> wrote:
> now is the time to speak up else we'll just be putting
> another band aid on this thing!
I know I've had my fair share to say on this topic, but I've look back
at the history and realise that last time I advocated for a
permissions based model was back in 2008 when Ron originally proposed
the http-method-exception (not called http-method-omission) as a
solution to this very issue.
My full response is below where I argued that it was overly complex
and did not meet the developers expectations. I think I can claim an
"I told you so" as it has indeed not solved the problem. The problem
was (and is) that developers don't really understand the security
model, so adding layers of complexity is hardly going to fix that
problem. We need a more intuitive security mode.
The current proposal tires to provide a "solution" by allowing
developers who don't understand the security model to just add a tag
and it will all be OK! It does not encourage them or help them to
understand the constraints they have. The true problem is the lack of
understanding and allowing uncovered methods is only one symptom of
that. I'm sure there are many other wrong security configurations due
to this lack of understanding.
If we really don't have time to finally come up with an understandable
security model, then I don't think the current proposal is going to be
any more successful that the last attempted fix. We should just add
logging to educate users about the omission constraints already
available and start work on a better model for the next iteration.
regards
On 9 December 2008 03:58, Greg Wilkins <gregw_at_mortbay.com> wrote:
> Ron,
>
> regarding, http-method-exception, there has been some interest expressed in
> something like a url-pattern-exception for filter, servlet and constraint
> mapping.
> So if we are to add method exceptions, then we should also add url
> exceptions.
>
> I think this would generally be a good thing that would help with the poor
> matching that we have.... but I'm a little cautious that it might end up
> being
> more complex than it looks at first.
>
>
> However, I'm not exactly sure how this element helps with the use-case that
> you cited: "there needs to be a definitive way to define (especially
> restrictive) the constraints that apply to all-other methods."
>
>
> I'm assuming that this is the case where you may have like
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Any User</web-resource-name>
> <url-pattern>/myapp/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>*</role-name>
> </auth-constraint>
> </security-constraint>
>
> and you wish to add a more restrictive constraint for
> posts to /myapp/admin.
>
> The issue being that many users currently think that they
> could just add:
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Any User</web-resource-name>
> <url-pattern>/myapp/admin/*</url-pattern>
> <http-method>POST</http-method>
> </web-resource-collection>
> <auth-constraint>
> <role-name>admin</role-name>
> </auth-constraint>
> </security-constraint>
>
> But the way the spec is currently written means that with
> the combination of these constraints, a GET request to
> /myapp/admin/something
> would not be constrained at all! (as the most specific
> URL is first match and then the method is not constrained).
>
>
> So are you saying that to assist with this issue, an additional
> constraint could be added:
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Any User</web-resource-name>
> <url-pattern>/myapp/admin/*</url-pattern>
> <http-method-exception>POST</http-method-exception>
> </web-resource-collection>
> <auth-constraint>
> <role-name>*</role-name>
> </auth-constraint>
> </security-constraint>
>
> that would re-apply the * role to the non-post requests?
>
>
> If this is the case, I feel that it is an overly complex
> way to specify constraints. I would prefer if we could
> come up with a way to allow the GET requests to be matched
> against the /admin/* constraint, rather than have the need
> to add a third constraint. But failing that, your proposal
> at least allows this hole to be closed (albeit verbosely).
>
>
> cheers
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.
Intalio, the modern way to build business applications.