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

From: Sergey Beryozkin <>
Date: Mon, 12 Nov 2012 09:59:13 +0000

On 06/11/12 18:53, Markus KARG wrote:
>>> I wonder how a client shall find out whether or not to show / hide
>>> particular GUI items (e. g. menu items directly related to the access
>>> rights of the current user) if the client cannot find out the access
>>> rights by pure http means. Is your proposed solution really to _not_
>>> use pure http means but build a particular application-specific
>>> protocol ontop? If yes, what good for is OPTIONS then?
>> To be honest I'm not sure how one can write a practical application by
>> depending on the list of verbs returned with OPTIONS
> Well... AFAIK the sole use of OPTIONS *is* to tell a generic client what
> methods are allowed to be called. If your concerns would be true, there
> would be no sense to enforce OPTIONS in the http protocol at all.
Lets say that I know of some practical use of OPTIONS, but I do not see
how a generic client, the one not written with the knowledge when POST
or PUT can be done, do something useful with OPTIONS.

>>> I mean, if it reports a method that the current user must never
>>> invoke?
>> I just think it would overload OPTIONS.
> Why?
>> IMHO the better approach is to offer a user/role-specific view,
>> example, a user logs in, and the server picks up say admins.jsp to
>> present a view. It is only the issue with monolitic UI frontends, isnt
>> it ?
> Agreed, but how does the current JAX-RS API draft support this alternative
> approach?
>> Also, IMHO, enforcing RBAC with @RolesAllowed is the most basic
>> approach, a number if options exist to enforce the method-level
>> authorization. Thus it seems to me it is out of scope for JAX-RS, given
>> that the 'responsibility' of the spec is to promote the ideas that can
>> lead to interoperable applications being created
> Well, it is the approach Java EE defines, and JAX-RS is part of Java EE. I
> do not say it must be the sole aproach, but it should be the mandatory basic
> one.
Well, if we talk about an HTTP client making the decisions on how to
talk to the server application, the fact that the server may've been
implemented with Java EE is an implementation detail of the server.

You are proposing for the spec to support for the client be written with
the specific knowledge that the server is running on top of EE.

How will this client application if someone rewrites the server with PHP
? Will that break the client expectations ?


> Regards
> -Markus