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