> Yes, I see why doing OPTIONS per every resource URI 'wired' to a
> specific action item and such can also work. Which approach is better
> JAX-RS 2.0 has to do with it.
>
> One of your thoughts was that it will let the client to avoid doing the
> extra calls in cases where the action is not actually allowed, but all
> you do is instead introduce *another round-trip with OPTIONS instead*,
> which will require JAX-RS (EJB) module do the job it is not supposed to
> do, aka, start checking '_at_RolesAllowed' as opposed to the security
> module doing it.
You are missing something: I do OPTIONS *once per resource* (OPTIONS /a,
OPTIONS /b). If there is @GET, @PUT, @POST and @DELETE defined for that
resource, I just need *one* request to learn about all four methods. Your
solutions needs *four* requests. So my proposal saves three of four calls.
It does not simply replace something. It really saves requests. Also, if the
GET would return lets say a megabyte of data, and the user never wants to
invoke GET, my solution reduces load -in this example- by one megabyte. I
won't say that this is not worth thinking about.
What do you mean with "the security module"? And who says that it is not the
JAX-RS modules' job to do that? The JAX-RS API defines a contract between a
container and a component. Just as the EJB contract defines security for
EJBs, the JAX-RS contract could define security for JAX-RS resources.
> Also, recall my note about PHP server. You'd expect the client
> experience be consistent and but it is likely the PHP server will be
> more modular and won't be able to get RBAC rules checked while
> processing OPTIONS.
I cannot follow. Can you explain it for dummies like me? :-)
> > But independent of any potential performance gain, cecking OPTIONS
> > first will always work with any methods, even with non-idempotent
> one.
> > Your idea of simply "trying it out" to adjust the GUI will fail at
> > least for the DELETE method as it would obviously delete information
> > just to find out whether it potentially could delete them... but the
> > GUI just wants to know whether the user MAY press the DELETE button,
> > but it doesn't want to actually DELETE anything just because the GUI
> is initialized.
> >
>
> As I said, this is the problem of monolitic UI frontends. I'd consider
> also another option, the user logs in, and gets the view formated on
> the server according to its RBAC provileges
What you propose is manual authorization handling inside the application
layer. What if the JAX-RS programmer does not want to code this manually?
What if likes this to be handles in a deeper layer (like authentication,
encryption and compression)?
You enforce a design that the JAX-RS programmer possibly does not want, or
cannot process (maybe client or server are already given and he must simply
add security ontop a fixed Web API), and it adds an unnecessary view layer
ontop of the already existing and working http application layer. I doubt it
is the JAX-RS application programmer's real interest to actively write lots
of code for security stuff (at least, in EJB it is not, thanks to
@RolesAllowed). Why reducing the programmer's choices?
> >> Do you expect POST be listed in Allowed ?
> >
> > "OPTIONS /" will never contain POST as there is no @POST method
> > defined for "/".
> >
> > "OPTIONS /a" invoked for "AdminA" WILL contain POST in Allowed, but
> > NOT when invoked for "AdminB" or others as your source defines that
> on "postA()".
> >
> > "OPTIONS /b" invoked for "AdminA" or others will NOT contain POST in
> > Allowed, but WILL for "AdminB" as your source defines that on
> "postB()".
> >
> >> How will you know that "/b" can not be accessed ?
> >
> > By requesting "OPTIONS /b" as "AdminA", as it does not return "POST"
> > in Allowed.
> >
> Sure this works - I do not agree it is a JAX-RS spec level issue
If you're sure it works, why did you ask it? And what spec level shall do
it, if not JAX-RS?
> > Okay now I may ask you a question:
> >
> > @DELETE
> > @Path("/a")
> > @RolesAllowed("AdminA")
> > public Response deleteA() {}
> >
> > How will your client know that "AdminA" is are allowed to invoke
> deleteA()?
> > Using my proposal, the client learns this by requesting "OPTIONS /a"
> > with user "AdminA", which returns "DELETE" in Allowed. 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), but
> when
> > then user then wants to DELETE actually, there is no more data to
> > physically remove, so you will get back a an error code. You GUI
> produces two problems. Mine none.
> >
> Please see above about the per-user role-specific view. I guess there
> are few more options possible
I took the time to answere your questions, please be so nice to answer mine,
too. You proposed sending the same request, so please answer on that basis
and you will know that that proposal will *not* work. About the view, see
above, it might not be in the interest of all JAX-RS users and you cannot
serve the others then. Mine will always work as nobody is forced to use it,
and still can provide a view like proposed by you instead.
>
> Sergey
>
> > Regards
> > Markus
> >
> >
>