On 16/11/12 21:10, Markus KARG wrote:
> 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.
OPTIONS /a
"Depth: infinite"
works partially, isnt it ? The above will return a single "Allow", the
intersection of say Allow from "/a" itself, "/a/d" and "/a/c". And
getting OPTIONS sent per every URI to which UI has some dedicated area
for sucks.
I think I will prototype something in CXF around X-options.
Either way, I'm -1 on getting JAX-RS runtime to do the
authorization-based filtering of Allow. It is up to you and other
experts to do the rest
Sergey
>
>> -----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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com