users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Can't get rid of @PreMatch

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Tue, 28 Aug 2012 18:22:13 +0200

On Aug 28, 2012, at 4:50 PM, Bill Burke <bburke_at_redhat.com> wrote:

>
>
> On 8/28/2012 10:25 AM, Marek Potociar wrote:
>>
>> On Aug 28, 2012, at 2:51 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>>
>>>
>>> On 8/24/2012 10:26 AM, Marek Potociar wrote:
>>>>>> What about the distinction between pre-post matching request filters? Do
>>>>>> we need that at all? Can we just have all "unbound" filters pre-matching
>>>>>> and all name-bound or dynamically-bound post-matching?
>>>>>
>>>>> I don't think we can do that (remove @PreMach). For example,
>>>>> something like @RolesAllowed is a name-bound filter and authorization
>>>>> should really come before as many filters as possible, don't you think?
>>>>
>>>> But isn't that something that may be completely resource-method
>>>> specific? IOW, doesn't it have to be done only after the resource method
>>>> has been matched?
>>>>
>>>
>>> I'll give you an example:
>>>
>>> We have a global server-side cache that is implemented as a set of filters. It "aborts" the request if there is a cache hit and returns the cached response. This *MUST* come after authorization. The cache is not name bound, but authorization is.
>>
>> Can your caching solution be changed to be name or dynamically bound (and then e.g. applied to the whole JAX-RS application)? Is there a use case where your users would benefit from selective caching possible with name/dynamically bound caching solution?
>>
>
> What you're requiring is that any filter that should be executed after authentication/authorization will have to be written as a dynamically bound filter. You may end up with a lot of insecure systems and/or security holes when a filter developer isn't aware of this issue.

We have not run into such issues in Jersey in 3+ years. How many users need to implement something as complicated as your caching use case? Isn't that something like a pre-made feature provided by the framework?

> When you think about it, @PreMatch is really just a special case of @BindingPriority. Maybe what you could do is define a new BindingPriority constant of PreMatch? Just throwing out ideas here. Like PreMatch could be -1 and all negative numbers pre-match, all positive numbers are post-match. I don't know, this idea here is quirky, but maybe it would work?

I'd rather keep @PreMatch in such case :) Btw. I'm, too, just trying to discuss to see if this is something redundant that could be removed from the API. I'm not pushing - just chatting about the options.

>
>
> BTW, the way the cache is triggered by Response cache-control headers set by the application.

I see. So you monitor all application responses and kick in based on presence of the cache-control header. Does it mean that you don't have a response filter that could be set and configured for each resource method and would take care of adding this cache-control header to the returned response?

Marek

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