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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>