Nice idea to spare even more workload, but what you propose is an extension
to http, while my proposal was 100% pure http. And I wonder why you want to
invent a special method for that, as it is the core intention of HTTPs'
OPTIONS method to tell the client all the possible options ALLOWED for a
given URI. So I would understand if you simply add another well-known header
like the "Depth: infinite" header of WebDAV to get the sub-URL answers you
intend.
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> Sent: Freitag, 16. November 2012 11:48
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Feature Proposal: Using @RolesAllowed for
> JAX-RS resources
>
> Markus, what do you think about this:
>
> Explore the option of extending OPTIONS, by introducing 'X_OPTIONS' or
> something similar...
>
> X_OPTIONS returns Allow for all the current URI but also for all the
> 'sub' URIS
>
> Consider:
>
> /a
> /a/b
> /a/b/c
>
> "OPTIONS /a" will return Allow possible on '/a' but not on 'a/b', etc.
>
> 1. X_OPTIONS /a returns, in pseudo HTML response:
>
> "/a : GET, PUT"
> "/a/b : PUT"
> "/a/b/c : PUT, POST"
>
> 2. X_OPTIONS /a/b returns, in pseudo HTML response:
>
> "/a/b : PUT"
> "/a/b/c : PUT, POST"
>
>
> 3. X_OPTIONS /a/b/c returns, in pseudo HTML response:
>
> "/a/b/c : PUT, POST"
>
> IMHO, it the very first step. If it were supported at HTTP level then
> the idea of doing a single 'pre-emptive' X_OPTIONS at the time a user
> of the monolitic UI which can deal with different resource URIs can
> become more interesting - I'd still debate whether it would be
> supported at the
> JAX-RS level, but at least it would be a start IMHO
>
> Sergey
>
> On 14/11/12 19:08, Sergey Beryozkin wrote:
> > I think I got what you were referring to with "can but does not want
> to"...
> > On 14/11/12 18:45, Sergey Beryozkin wrote:
> >> On 14/11/12 18:20, Markus KARG wrote:
> >>>> 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.
> >>
> >> "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.
> >>
> >
> > I guess you thought I suggested "to send DELETE" before the user who
> > 'can but does not want' to actually chooses to press "DELETE".
> >
> > Is that right ? If yes then let me clarify that no, I did not mean
> that.
> > It is not possible to implement in the monolitic UI.
> >
> > My idea was: if the user presses "Delete" button - then send DELETE
> if
> > we get 403 then disable the button and show the error message in the
> > console.
> >
> > In you case you will do OPTIONS per every specific resource URI.
> Which
> > is more expensive in cases where a given logged-in user does have all
> > the rights to do all the actions - the more rights the user has the
> > more expensive your approach becomes.
> >
> > With my approach the cost is none for the users with most rights.
> > If the user has the limited rights then the only cost is the single
> > futile attempt to invoke some action on a given resource - but you
> > don't win here either with OPTIONS round trip
> >
> > Cheers, Sergey
> >
> >
> >> Sorry, may be I'm missing something
> >>
> >>>
> >>> 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).
> >>
> >> I think it is debatable, but I won't go there
> >>
> >>>
> >>> 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.
> >>
> >> 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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >>