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!
:-)
> >> 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