On 16/11/12 21:04, Markus KARG 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.
>
> Yes I thought you mean that.
>
>> 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.
>
> I understand your idea but it does not provide an intuitive GUI. I mean hey,
> a button that is enable first and once I pressed it jumps to disabled state
> is everything but user friendly. Users expect that the GUI has all buttons
> disabled right from the start.
>
>> 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.
>
> This is not true. It does not scale with the current user's rights but
> solely with the number of visible buttons or menus on the screen (which is
> static). For example, you can show a table with 20 resources, have one menu
> bar with things like "[Delete][Edit]" and so on at the top. To build that
> GUI you just do one single OPTIONS call for the currently (initially)
> selected row of the table to learn about all allowed actions on that
> resource, in turn enabling or disabling [Delete] and [Edit]. When the user
> selects a different row, you invoke another single OPTIONS on that newly
> selected row to learn about the new authorization, in turn enabling or
> disabling... and so on. As this implements the "last possible point in time"
> paradigm, it executes the least possible load but has the ultimately current
> and responsive GUI.
>
>> 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
>
> I think with "your approach" you mean the idea of sending a full view?
>
> Then this is assumption is not true, the cost is not "none", as you must
> produce, transfer, parse the information for *all* 20 rows in the initial
> invocation *and* have to implement a background thread to poll the status
> updates periodically for *all* 20 rows -- since possibly the browser was
> left open for some time (in the meantime the user might have granted more
> rights) so when moving the selection bar my solution will be up-to-date
> while your GUI will show outdated information.
>
> What your solution spares is roundtrips, but not real workload or
> transferred volume. Calculate a real world example in real bytes not making
> any assumptions like "it is ok that the GUI is outdated" etc. and you will
> notice that my solution is superior.
>
In the end of the day, may be you are right. Or may be not: HTML-centric
UIs are on the rise, and modular UI (aka where every part of it is
linked to a bigger whole via references and such) is easy to build on
the server and let the browser do the presentation with all
enabled/disabled from a start.
I've found this discussion to be quite interesting to be honest.
I'd encourage to not try to get JAX-RS runtime deal with the diff level
responsibilities - and to be honest this is my main objection. I know
you asked for the ESB-specific module only to support it - my concern
would be people will request it be supported across the all JAX-RS
integration modules. Writing and testing a filter which can easily check
@RolesAllowed is easy - I can share the code from the existing CXF
interceptor which does it
Cheers, Sergey
> Regards
> Markus
>
>
>