> > 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.
>
> "If the user *can* delete but does not *want to*", - what is it really
> about. Authorization (RBAC, etc) is about preventing an unauthorized
> user to invoke a given service action/method.
>
> So I do not understand you saying "can but does want to" - the user
> either can or can not.
>
> Sorry, may be I'm missing something
The scenario is that a monolitic GUI wants to disable all buttons (i. e.
show them in a visual style that indicates it is there but not "pressable")
that a user may not press currently as he has no authorization to do so. The
GUI issues an OPTIONS request to learn about the fact that the currently
authenticated user IS ALLOWD TO ("can") press the delete button (it is NOT
visually greyed). Whether or not the user presses this button, is at his
sole will.
Your initial idea was to replace OPTIONS by DELETE as you said OPTIONS is
not needed for this scenario. I said this works for GET but not for DELETE,
as obviously the GUI setup will then delete stuff long before the user can
decide whether or not the presse the "Delete" button.
What actually do you not understand in this scenario? Unless you provide a
server-generated view (what I said some people might not want or cannot) you
ulitmatively need OPTIONS and cannot replace it by DELETE.
> > 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.
> >
>
> I'm actually thinking that we kind of agree here, partially. The only
> diff is that you think it is the job of the JAX-RS runtime to deal with
> security related annotations and I don't. I don't care a lot about EJB
> and hence may be I'm missing something.
I also think that we want the same but just come from different history.
Maybe it would be good if the other experts chime in?
>
> Cheers, Sergey
>
> > Regards
> > Markus
> >
> >>
> >> Sergey
> >>
> >>> Please see above about the per-user role-specific view. I guess
> >>> there are few more options possible
> >>>
> >>> Sergey
> >>>
> >>>> Regards
> >>>> Markus
> >>>>
> >>>>
> >>>
> >>>
> >
> >
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com