On Aug 28, 2012, at 8:50 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> 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.
We have a "roles-allowed" filter that is name bound. And I know it was slightly complicated to implement correctly. But those 2 are perhaps the only such use cases I know about.
> 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.
:) ok. very diplomatically put. (I applaud) :)
>
>>>
>>>
>>> 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.
Ok. Let's keep the @PreMatch then. I wish we would receive more feedback from EG on these topics (sigh).
Marek
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com