On 21/11/12 19:37, Markus KARG wrote:
> Bill,
>
>>>> RoleBasedSecurityFilter/Feature.java
>>> * This code is not vendor-agnostic as it contains
>> ResteasyProviderFactory.
>>> As I am an ISV, I do not like to bundle another vendor-specific
>> filter
>>> for every possible JAX-RS container on the market with my application
>>> (effectively breaking WORA). Would it be possible to replace
>>> ResteasyProviderFactory by a pure JAX-RS thing (otherwise your code
>>> would be a good proof that it is impossible for an end user to write
>>> such a filter, hence there must be a JAX-RS solution be added to the
>> spec)?
>>>
>>
>> Whoops. Good catch. You can inject SecurityContext via @Context.
>> I'll make that change. Not sure why I did it that way to begin with.
>> Maybe its just because it evolved from really old code.
>
> Understood. So it should work with Jersey, too.
>
>>> * I do not understand how the @RolesAllowed, @DenyAll and @PermitAll
>>> annotations found at different JAX-RS resource methods make their way
>>> into your filter constructor. Your code looks to me like if the
>>> annotations would be statically linked to the filter for all JAX-RS
>>> methods, effectively being application-wide, while actually must
>>> instead be working per-resource-method. Is that a JAX-RS feature I
>> did miss in the spec?
>>>
>>
>> RoleBasedSecurityFilter is a per-method filter. Look at
>> RoleBasedSecurityFeature.java
>
> Thank you for pointing me to this. Looks exactly like what I wanted to have.
> +1 for making "RoleBasedSecurityFilter" a mandatory feature of JAX-RS 2.0!
> :-)
>
Come on, just ask Marek to consider adding a richer ResourceContext
context interface and do whatever you want with it,
Sergey
>>>> I haven't followed this conversation, but you're specifying a custom
>>>> protocol? Because I'm pretty sure Allow header has no relationship
>>>> with main security protocols.
>>>
>>> No I am not proposing a custom protocol but simply applying the very
>> core
>>> idea of what OPTIONS's "Allow" is intended to be used for: Telling
>> the
>>> client what methods are allowed to be called by this client. The http
>> RFC
>>> does not limit the sources where this information is taken from. JAX-
>> RS
>>> currently simply assumes that the pure existence of a resource method
>> turns
>>> this into a valid member of the "Allow" header, but the http RFC
>> allows us
>>> to further limit the set of members of the "Allow" header. In my
>> proposal, I
>>> simply say I further reduce this set in case of authenticated
>> requests.
>>>
>>
>> Sorry, but I think you are overloading Allow. BTW, I think the whole
>> default behavior for OPTIONS and Allow is junk anyways. I just find it
>> very hard to believe anybody could get anything useful out of so little
>> information. I even think the OPTIONS method in HTTP is junk and
>> useless too. In the real world you are going to be provided with a
>> link
>> to metadata that describes the service (or set of services) (i.e. a
>> yucky, icky WADL document). Or, your media type will be self
>> describing
>> (i.e. HTML).
>
> I do not see why you think it is overloading. All I proposed was checked
> against the http RFC and is a valid extension that will comply to the
> expected behaviour of OPTIONS. :-)
>
> Actually the use case where this is useful was already described in this
> thread many times, and I do not demand this just for fun. This *is* a
> real-world demand, and I do not want to reinvent the wheel on a higher level
> custom-protocol if the http specification already declares a generic
> solution for that. In fact I do not force that JAX-RS must implement this
> handling, I just proposed it as it will provide a benefit but do no harm to
> anybody (as I described, it actually reduces the harm already done by JAX-RS
> by reporting non-allowed methods -- which I would more see like a bug fix!).
> All I really need is an interface that allows me to query this information
> so I can reduce the automatic OPTIONS response to the *actually* allowed
> methods. I looks like your code is a good starting point, so I'll check if I
> can build this ontop. :-)
>
> Regards
> Markus
>