On Jul 12, 2008, at 4:57 PM, Bill Burke wrote:
> Was thinking more about our possible regexp expansion. One thing
> that screws it up is Subresource Locators. For example:
>
> @Path("{foo:.*}")
> public Object find(@PathParam("foo") String foo)
> {
> return new Bar();
> }
>
>
> public class Bar {
>
> @Path("a/b/c")
> @GET
> public String get() {}
> }
>
>
> Let's say the HTTP request is:
>
> GET /a/bunch/of/stuff/a/b/c
>
> @PathParam foo would always eat up the whole URI.
>
>
> This is yet another thing I dislike about dynamic Subresource
> locators.
I don't think this is a problem with sub-resource locators per-se, its
just an issue of being careful with your @Path values. That will apply
in spades if we allow specification of the regex for a path param.
> If you don't remember I also talked about the problem of not being
> able to authenticate before invoking on the resource locator since
> you would need @RolesAllowed available.
>
On that topic I've been working with our EE security architect to try
to come up with a solution. We don't have anything fully baked yet but
are thinking along the lines of specifying a servlet 3 compatible path
that would point at JAX-RS resource classes rather than identifying
URI paths. With this you'd be able to put something like this in a
web.xml to constrain access to a resource:
<security-constraint>
<display-name>Constraint1</display-name>
<web-resource-collection>
<web-resource-name>Foo</web-resource-name>
<url-pattern>jaxrs:///resources/Foo</url-pattern>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>Have to be a user to POST to the Foo resource
class</description>
<role-name>USERS</role-name>
</auth-constraint>
</security-constraint>
Or something like that anyway.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.