Re: checkAccess method in DataObjectMaster ?

On 3/04/2010 0:39, [email protected] wrote:
> Sorry, been distracted :)
>
> The method is unfinished. It has no bearing on blocks and should be
> adjusted to reflect the structure of dataobject masks. I plead leniency
> because I wasn't having it be used anywhere yet :)
>
No problem - it's functioning now with the existing security checks ;-)

> ...
> 1. I am not quite sure where to store the mask (access) information.
> Dataobjects have a configuration field which could fit the bill for
> instance.
>
> 2. I wasn't quite sure how to deal with the objects/items dichotomy.
>
> A simple example would be to add a mask to each of the object's main
> methods, allowing us to easily (and dynamically) change access
> requirements on each one for creating, displaying etc.
>
Have a look at the modified checkAccess for the different methods 
(actions) that are listed there, which are then mapped to the
security levels used in the GUI/API for object items.

I've added a 'config' action, which corresponds to modifying the
object definition and properties of an object, and can also be tied
to each object.

The only level that's really missing then is the ability to define new 
objects, possibly for a particular module, e.g. new article pubtypes, or 
new xarpages types etc. This can't be tied to the object itself, so 
there the normal security checks would apply.

> I have to say I haven't really thought enough about the UI handlers as
> yet to be able to make any useful comments to that effect.
>
That (and the GUI/API) are the main places where security checks are 
done in DD today, and they have an object instance handy, so I thought
I'd start there ;-)

> The secondary agenda here is that successfully applying the access
> property to data containers or objects such as DD encourages their
> application in other areas. Thus over time we may be able to run all of
> Xaraya with a few such container types, such as blocks, dataobjects,
> xarpages, articles...
>
Using checkAccess() doesn't necessarily mean using the access property,
and/or storing the access configuration with the object itself. I'd
like to give that part a bit more thought before we drop the usage of
xarSecurityCheck() inside checkAccess().

You're basically changing several things here:
1. granting access directly based on group membership
2. storing the access configuration with each object
3. loosing the ability to check access without object
4. using the access property to check access

The first is a nice simplification, see e.g. the simple mask-based 
security checks by group. But the way it's implemented today doesn't
allow for several group memberships per level (or vice-versa) yet.

The second is a bit trickier, because this makes it more difficult
to manage access from a central place afterward - but on the other
hand tying ACLs to the objects could be a good thing too. We could
even integrate filtering by value in specific cases.

The third means that we'll still need security checks and access
levels outside the object, even within DD itself. So we need to
think about how those security models will fit in eventually. Also
needing to instantiate the object before checking access is a bit of
a performance waste, but that's another issue...

The fourth is a handy implementation example, but it shouldn't be
generalized yet until we have a better grasp on the other issues IMO.

> BTW one of the things that this exercise shows up (for me anyway) is
> that in some cases we may have shot beyond the mark: the privileges
> system in this case may be too finely grained for most real world
> situations.
>
> Marc

True - in DD the *Field masks are definitely overkill, and for the
*Items masks checking on specific itemid's is often unnecessary
as well (but not always perhaps). And of the generic DD masks,
only AdminDynamicData and EditDynamicData are really used today.

What can I say - we tried to be complete in the early days, before
understanding how this would really be used - sounds like me ;-)

Mike.