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