Skip to main content

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

  • From: Sergey Beryozkin <sberyozkin@...>
  • To: <jsr339-experts@...>
  • Subject: [jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources
  • Date: Wed, 21 Nov 2012 22:28:37 +0000

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



[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

(continued)

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

Markus KARG 11/17/2012

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

Sergey Beryozkin 11/20/2012

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

Markus KARG 11/20/2012

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

Markus KARG 11/16/2012

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

Sergey Beryozkin 11/16/2012

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

Markus KARG 11/17/2012

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

Bill Burke 11/20/2012

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

Markus KARG 11/20/2012

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

Bill Burke 11/21/2012

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

Markus KARG 11/21/2012

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

Sergey Beryozkin 11/21/2012

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

Markus KARG 11/16/2012

[jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for JAX-RS resources

Markus KARG 11/14/2012
 
 
Close
loading
Please Confirm
Close