Re: Security checks for modules and module items revisited

mikespub wrote:
> While trying out the dyn_example module with object->checkAccess(), I 
> hit the issue that normal security checks in dyn_example use their own
> security masks ViewDynExample, ReadDynExample, EditDynExample etc.
> 
> My first reaction was to support overriding the default DD security
> masks in object->checkAccess somehow based on the masks defined by the
> 'owner' module, but then I started wondering what the point of those
> security masks for module items was if DD controlled the access anyway.
> 
> Which led me to the conclusion that for simple cases like dyn_example
> we might as well get rid of module-specific security masks to control
> the access to items, and let DD handle them. 

Agree, for sure in this case, and I don't see why not throughout Xaraya.

This leaves the following
> open issues:
> 
> 1. access to the module admin part (= independent of DD objects), which
>    could conceivably be replaced by some generic module->checkAccess()
>    routine for all modules.

Perhaps the implicit assumption here is that mask instances have to do 
with object (or other data container) items. Even if that is so we still 
have cases where components are used, e.g. roles objects vs. the links 
between roles.

In DD this may not be the case and so you could make do with generic 
access checks, but why bother? Masks without instances ("generic") can 
be tested against as long as they are centralized as they are now. I'm 
assuming you're proposing getting rid of that. If not what would be the 
difference to the masks we have currently (apart from adding the group 
access component)?

> 2. use of the old security masks in xar:sec tags in module templates,
>    which could be replaced if we have an object instance in the template

Replaced by a new generation of checks which contain the object access 
component. I just realize I forgot to mention I created an access tag in 
privileges some time ago that runs on the access property check. It's a 
generalization of the sec tag if you will. Maybe useful in this context? 
or generalizable?

> 3. use of the old security masks to build up items for the admin menu,
>    which would require instantiating an object instance for the menu

Not sure I understand this.

> 4. other restrictions based on module functionality that has nothing to
>    do with objects or generic module access (= not in dyn_example).
> 
> Only the last one requires specific security masks (or something) - the
> others could be solved with either a generic module checkAccess() or
> adapting the module to rely on object checkAccess() for module items.
> 
> Any thoughts on any of those options ?

I keep trying to bring this all under one consistent conceptual 
framework, but can't quite get it. Access to data and access to code 
seem things far apart, unless we convert the code to classes and treat 
them the same way as DD objects, or at least unless we conceptually 
treat our functions like discrete "objects". [And to some degree this is 
doable or already done following the pattern of new/create, 
modify/update and so on. But one of the "advantages" of procedural 
functions as opposed to classes is precisely that you can just write a 
function without having to think too much about how it fits in 
conceptually in the overall scheme of things. So in the end this chaotic 
freedom works against your getting a module's functions into some nice 
consistent schema you can apply access rules to.]

Given that the issue of access to data appears more consistently 
manageable, I'm happy to see where that path takes us (as we have been 
doing with this new approach) and bring on (or not) access to code later on.

Marc