Re: Security checks for modules and module items revisited

On 8/04/2010 14:40, [email protected] wrote:
>>...
>> 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)?
>
I was thinking more of the basic building blocks we have in the Xaraya 
world, i.e. modules, blocks, dataobject items etc. and how each can be
checked for access, based on how xarSecurityCheck was used in the past.

We already have block checkAccess and dataobject checkAccess now, which
correspond to two of those basic building blocks. So why not have a
third base class that corresponds to modules, and that can be used to
check access to module code where the others don't really fit ? Like
the generic admin overview, modifyconfig or utility functions etc.

That way most modules could rely on module checkAccess, object 
checkAccess or block checkAccess depending what they're dealing with,
and we wouldn't really need to define specific security masks in each
module again and again (except for special cases like point 4. below).

>> 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?

OK, I guess we'll need to review the xar:access tag to handle both 
blocks and objects then.

>> 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.
>
Just walking through all xarSecurityCheck calls in the dyn_example
module here - this was one place where we had no object instance to
rely on.

>> 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.]
>
I agree in theory - and we shouldn't drop the idea of components and
security masks altogether either for those special cases. It's just
that many modules don't really need those in practice, and we keep
copying & adapting the same security masks and components over & over
for each module.

Getting rid of specific block masks was one step, getting rid of "item"
masks (for modules using DD) is another. Getting rid of "module" masks
would be the next step - that's what I'm trying to say ;-)

> 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

OK, I'll give this some more thought as well, and see if I can come
up with an example that makes sense ;-)

Mike.