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