Greg Wilkins wrote:
> Craig R. McClanahan wrote:
>
> > The workaround I suggest is to use URL patterns like "/*", or directory names
> > with only digits in them, if this is an issue for your application.
>
> I agree here, but there is still more spec clarifications required
> before you can specify portable security in a web application:
>
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.
>
> 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.
>
> If you deploy with no constraints at all in your web.xml (or the
> default web.xml), then the spec does imply that you will allow PUTs
> to your site.
>
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.
>
> This probably is not a current problem, as many servers either don't
> support PUTs or disable them with a non-standard mechanism. But
> you have to think about it if you want your web app is going
> to be deployed on unknown servers.
>
> 1) It would be nice to specify a restrictive default constraint, and
> then relax it for specific URL mappings. But the spec does not say
> that the most specific security constraint applies.
> But that is probably a safe bet to make?
>
> 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".
> Thus if you restrict access to "/*" for a web app, then there
> is no mapping available relax that restriction
> on the root URL "/". Thus are request to http://host/context/
> will always be treated with the default security constraint.
>
See the servlet spec for the details.
>
> 3) The spec does not define a relaxed constraint. How is the
> following constraint interpreted?
>
> <security-constraint>
> <web-resource-collection>
> <url-pattern>/blah/*</url-pattern>
> </web-resource-collection>
> </security-constraint>
>
> Does it mean "no access on /blah/*" or "no constraints on /blah/*".
> Jetty currently assumes the former to be safe and uses a special
> role name NONE (non-standard) to specify relax access:
>
>
> <security-constraint>
> <web-resource-collection>
> <url-pattern>/public/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>NONE</role-name>
> </auth-constraint>
> </security-constraint>
>
> --
> 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
