Re: [Exist-development] My vision about admin RESTful URLs

[Joe W. <jo...@gm...>]

Hi Thomas,

> An ‘area’  is very similar to ‘role’, although an area could be created with
> roles or groups or whatever means the current implementation offer to allow
> XML resources to be read only by authorised users.

What you said sounds reasonable -- in that you're relying on other
mechanisms (read privileges, granted through the builtin unix-style
permissions or XACML) for authorization, rather than reinventing the
wheel through some predetermined, hardcoded URL-based scheme.

> In every area collection, for every action we have an XML file that can be
> read only by the group or role authorised for this area,  say ‘system-admin’
> group:
>
> /admin/system/server/action-restart.xml
> <action>
>     <id>restart</id>
> </action>

I like the idea of action XML files for augmenting authorization,
although these files needn't necessarily be stored in an area
subcollection.  These XML files could conceivably be stored in a
single, common collection.  I would say that 'area' in your proposal
is merely a convenient way to group actions together into a collection
so that permissions can be applied to the whole collection, rather
than on a file-by-file basis.  It's an internal permissions issue.  I
don't yet see a compelling reason why this issue should impact the URL
design, in terms of requiring that 'area' be a part of the URL.  In
other words, it seems to me that your notion of 'area' is still an
authorization concept, rather than a concept that should drive the URL
or application organization.  The weakness in organizing an app around
preconceived notions of user groups is that authorization needs are
different for just about every organization.

That said, I think the most compelling claim you've made for
organizing the admin section around 'area' is in that it could help
the admin section be modular -- letting developers select groups of
admin actions for their applications.  This is a very different goal
than an 'authorization' goal, and I agree that it's desirable.  But I
haven't seen how 'area' helps achieve that flexibility from what
you've said.  Is there anything you could add that would back this
claim up?  Could you flesh out where action-restart.xql/m would be
stored relative to the main admin xquery file, and how a developer
could disable this action from their app without trouble?

I think the questions for everyone are:

1. Do folks think XML files that describe atomic admin 'actions' are a
good way to handle authorization?  If so, should the 'action' XML file
be organized into pre-determined 'area' sub-collections, or should the
grouping of these files be left to the individual developer?

2. Does this notion of 'area' really help the admin app stay modular?
What's the best way to organize the admin app so that both groups of
actions and individual actions can be turned on/off?

Joe