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

From: Sergey Beryozkin <>
Date: Wed, 14 Nov 2012 18:45:24 +0000

On 14/11/12 18:20, Markus KARG wrote:
>> Was just checking the above - it does not make sense at all:
>> "Using your idea in contrast, you will never know, as in your first
>> DELETE invocation the data is deleted (what the user possibly did not
>> want to)".
>> If the user is in role then the delete will be allowed, if not - 403
>> will be returned. Yes, I can see how with OPTIONS you can do it the
>> other way around, but it's not a JAX-RS level issue. Just add a pre-
>> match filter operating an OPTIONS and do the analysis of RolesAllowed
>> and get your list of allowed methods...
> It *does* make sense. You proposed that you can simply send the same request
> twice so a monolitic UI can learn what buttons to enable and which to
> disable. If the user *can* delete but does not *want to*, your initial
> DELETE to disable the buttons will effectively destroy data. Your proposal
> of simply sending the same request twice only works for idempotent methods,
> not for others. So it is not useful.

"If the user *can* delete but does not *want to*", - what is it really
about. Authorization (RBAC, etc) is about preventing an unauthorized
user to invoke a given service action/method.

So I do not understand you saying "can but does want to" - the user
either can or can not.

Sorry, may be I'm missing something

> Your other idea (sending an initial view) is not covering cases where a
> monolitic UI is wanted. It solves only our personal likes, while mine adds a
> real value (declarative style, offloading to lower http levels, no risk of
> coding mistakes in the filter).

I think it is debatable, but I won't go there

> About the levels, we just have different understand what the container shall
> do and what not do, and what the resource programmer's job is and what not.
> I see JAX-RS as a parallel thing to SLSB EJB. SLSB EJB is RPC over IIOP and
> solves the security in a declarative style. JAX-RS is REST over http and
> should solve the security in a declarative style, too. I do not want to put
> the burden and risk implied of writing such a filter on the shoulders of the
> programmer just because he decided not to use RPC/IIOP but to use REST/http.
> This would be a step backwards in the idea of integrating EJB with JAX-RS.

I'm actually thinking that we kind of agree here, partially. The only
diff is that you think it is the job of the JAX-RS runtime to deal with
security related annotations and I don't. I don't care a lot about EJB
and hence may be I'm missing something.

Cheers, Sergey

> Regards
> Markus
>> Sergey
>>> Please see above about the per-user role-specific view. I guess there
>>> are few more options possible
>>> Sergey
>>>> Regards
>>>> Markus

Sergey Beryozkin
Talend Community Coders