On 8/28/2012 12:22 PM, Marek Potociar wrote:
>
> 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?
>
You probably have not run into this issue because you don't have any
name-bound auth. I've been dealing with the interceptor pattern for a
long time now in different frameworks and ordering can be pretty
sensitive, especially when it comes to security.
BTW, The use case really isn't that complicated. Its a request filter
and a mbw interceptor. Plus, now, because of JAX-RS 2.0 it is a
*portable* feature to jersey, et. al.
>> 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.
>
I applaud your effort to reduce and refactor. Its a good discussion,
but I'm not sure it can work.
>>
>>
>> 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?
>
A filter does not add a cache-control header, the application does. The
response filter decides to cache based on whether the app set the
cache-control header. Like I said, there's no reason i couldn't write a
DynamicFeature that just forced the request filter to be name-bound, but
it just seems wrong.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com