jsr339-experts@jax-rs-spec.java.net

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Tue, 13 Nov 2012 12:02:40 +0000

On 12/11/12 19:27, Markus KARG wrote:
>
>> 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 ?
>
> No I do not proposing the spec to support anything special in the client for
> anything special in the server, please carefully check what I actually
> proposed. The client is dependent of pure http. The server is producing pure
> http. The only relation to Java EE is on the server side.
>
> As the interface is defined by pure http means, certainly such a client will
> run rather perfectly with PHP server. I do not bind the client to anything
> server specific. Nothing broken.
>

OK, lets talk practical.

here is my resource:

@Path("/")
public class Resource {
   @GET
   @Path("/a")
   @RolesAllowed("AdminA")
   public Response getA() {}

   @POST
   @Path("/a")
   @RolesAllowed("AdminA")
   public Response postA() {}

   @POST
   @Path("/b")
   @RolesAllowed("AdminB")
   public Response postB() {}
}

The (UI) client logs in, and it's allocated 'AdminA' role. The UI can
access '/a' and '/b'.

Here are my questions:

At what point do you expect to ping the runtime with OPTIONS ?

Why it will be cheaper (and also less expensive for the server) than
attempting to access '/b' and disable the button allowing the user to
access "/b" upon the authorization failure ?

Do you expect POST be listed in Allowed ? How will you know that "/b"
can not be accessed ?

Sergey