"Craig R. McClanahan" wrote:
>
> Note: any suggestions for spec clarifications should be sent to the email address
> on the front of the spec ([EMAIL PROTECTED]) to ensure that they get
> formally addressed.
Yep - I've posted some questions there, but as spec changes will be a long time
coming, I'm interested to find out how other interpret the current spec.
> > 0) As methods such as PUT, MOVE and DELETE are controlled by security
> > constraints, then this may be an issue for more applications than
> > you'd think.
> That depends totally on whether or not the servlet executing this request supports
> PUT. Unless it does (i.e. you have a doPut() method, or you override service() and
> check the request method yourself), a PUT is not going to modify your web site --
> security constraints or not. Same for the other methods.
PUT can create new static content, so there may not be a servlet there
at all. Even if the container implements static content with a servlet,
then that servlet should implement PUT and take it's configuration
from the deployment descriptor.
> > 2) "/*" is not well defined in the spec, as it's obvious meaning
> > is overloaded by the definition of "/" as the default mapping,
> > so really "/*" == "/".
> This is not correct at all. The "/*" mapping means "use this mapping for every
> request processed by this webapp." The "/" mapping means "use this mapping *only*
> if no other mapping matches".
Sorry I did not make myself clear here - I meant "/" as a path not
as a pattern. As mappings "/" and "/*" are different (in that /* takes
precidece over *.jsp, while / does not).
What I am trying to say here, is that if you constrain access
to "/*" then there is no way for you to create a more
specific constraint for the a URL of "/".
I think an example would help. I want to protect all the content of
my webapp except /public/* and /index.html.
So I create a security constraint at "/*" to constrain access.
I then create a relaxed constraint at "/index.html" and "/public/*"
to allow access.
But if somebody makes a request to
http://host/context/
You would expect it to be forwarded to http://host/context/index.html
But it is caught by the /* security constraint and denied (or constrained)
Thus any paranoid webapp is denied the ability to have a
public default index.
Is that clearer?
However I was wrong in my previous post when I said:
> I can't put a servlet at / and wear the cost of the double
> dispatch of every request, because the content might be
> a dynamic JSP and *.jsp takes precident over /
Because as you say, I can put a servlet at /* which takes
precedence over *.jsp
Thus the only portable way that I can think of to protect
a directory of arbitrary content is to front it with a
servlet and roll-your-own security.
It would be preferable to use the security constraint
mechanism - so that it can controled via the deployment
descriptor.
Which brings me back to my original questions regarding
clarification of the meaning of multiple and empty
security constaints?
--
Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)2074394045
Mort Bay Consulting Australia and UK. Mbl Phone: +44-(0)7775534369
http://www.mortbay.com AU Phone: +61-(0)2 99772395
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
