> > 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.
> > 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.
Regards
-Markus