Sergey,
thank you for your comments.
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? I mean, if it reports a method that the current
user must never invoke?
Thanks
Markus
> The idea of "(4) The JAX-RS's automatically provided "Allow" header for
> an OPTIONS request will omit any HTTP methods which would be not
> executed following the sense of (3) when requested with the same
> security credentials as the OPTIONS call (i. e. either unauthenticated
> or authenticated as the same user)." does not work.
>
> It really the server side issue, making sure the authenticated client
> is properly authorized, so I'm not sure what Options is to do with it,
> I can already hear the security experts saying this would allow a
> rogue client to use this mechanism to expose the info the client does
> not need to know.
>
> Now, in UI frontends, it it handy sometimes to block certain actions
> based on the client's identity. This still can be resolved by offering
> client specific views (presented after the initial login) and in cases
> when the UI is to rigid, it is a completely out-of-scope activity for
> JAX-RS anyway.
>
> I'm -1 on it