> Was just checking the above - it does not make sense at all:
>
> "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)".
>
> If the user is in role then the delete will be allowed, if not - 403
> will be returned. Yes, I can see how with OPTIONS you can do it the
> other way around, but it's not a JAX-RS level issue. Just add a pre-
> match filter operating an OPTIONS and do the analysis of RolesAllowed
> and get your list of allowed methods...
It *does* make sense. You proposed that you can simply send the same request
twice so a monolitic UI can learn what buttons to enable and which to
disable. If the user *can* delete but does not *want to*, your initial
DELETE to disable the buttons will effectively destroy data. Your proposal
of simply sending the same request twice only works for idempotent methods,
not for others. So it is not useful.
Your other idea (sending an initial view) is not covering cases where a
monolitic UI is wanted. It solves only our personal likes, while mine adds a
real value (declarative style, offloading to lower http levels, no risk of
coding mistakes in the filter).
About the levels, we just have different understand what the container shall
do and what not do, and what the resource programmer's job is and what not.
I see JAX-RS as a parallel thing to SLSB EJB. SLSB EJB is RPC over IIOP and
solves the security in a declarative style. JAX-RS is REST over http and
should solve the security in a declarative style, too. I do not want to put
the burden and risk implied of writing such a filter on the shoulders of the
programmer just because he decided not to use RPC/IIOP but to use REST/http.
This would be a step backwards in the idea of integrating EJB with JAX-RS.
Regards
Markus
>
> Sergey
>
> > Please see above about the per-user role-specific view. I guess there
> > are few more options possible
> >
> > Sergey
> >
> >> Regards
> >> Markus
> >>
> >>
> >
> >