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.
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?
BTW, the way the cache is triggered by Response cache-control headers
set by the application.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com