dev@jsr311.java.net

Re: JSR311: expanded regexp and subresource locators

From: Bill Burke <bburke_at_redhat.com>
Date: Mon, 14 Jul 2008 10:19:39 -0400

Marc Hadley wrote:
> 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.
>

No, its a problem with sub-resource locators. Consider this:

@Path("/")
public class FindJmsQueue {

    @Path("{path:.*}")
    public QueueResource find(@PathParam("path") String lookup) {
       Destination queue = jndi.lookup(lookup);
       return new QueueResource(queue);
    }
}


I'm decoupling the lookup from the actual resource that handles Queue
processing. If JAX-RS only did static sub-resource locators, I could
have any arbitrary path followed by concrete, well-known, resource
endpoints. I hope you're following me. I know others have shown
similar examples to this.



>> 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.

The solution is simple. Change the damn servlet spec to have richer
url-patterns. Its ridiculous it is so limited and we have to define our
own JAX-RS specific resource security.

> 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>
>

Unless I'm missing something, seems very very very very Glassfish
specific. No thanks...


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com