[Zope3-dev] Re: security frustrations

Dominik Huber dominik.huber at perse.ch
Wed Aug 10 04:04:09 EDT 2005


Florent Guillaume wrote:

> Does it work to just set __parent__ to the container? Or does the 
> zopesecuritypolicy require more accurate context?

Yes, the unset location is the problem, why  the local security cannot 
be looked up.

Martijn Faassen wrote:

> Benji York wrote:
>
>> Martijn Faassen wrote:
>>
>>> * after object creation but before the object is added,
>>>   various things are done to the object.
>>>
>>  > * authorization error: user cannot access various attributes.
>>
>> If these things are done by subscribers, would using trusted 
>> subscribers help?
>
>
> I guess it could; I've used a trusted adapter in a few places to get 
> around security concerns.
>
> However, not everything is done by subscribers. I have a little 
> workflow system that in some cases can create new versions of objects, 
> for instance.
>
> My frustration is more that one has to do *something* special than 
> that there aren't any solutions. Knowing to use trusted subscribers 
> and having to design ones application around them would be another 
> thing one would need to know to 'please' the security system. I know 
> of course that security is hard, so maybe there's no way than to just 
> bite the bullet... 

A year ago we wrote a little initializer framework 
(svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/initializer) that offers a 
possible *general* way to initialize components. A inializer subscribers 
is hooked in using the ObjectAddedEvent. At that time the component is 
already located within its parent and all intialisation actions can be 
performed (including utility registration etc.):

Summary 
(svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/initializer/README.txt)
- Offers class- or adapter-based inialisation ( -> ClassInializer, -> 
FeatureInializer)
- Takes inheritence during initialisation (reversed rmo) of classes and 
adapters into account
- Offers initalisation data handling using keyword arguments and a 
signature specifying those arugments
- Supports the form framework (-> add form, add wizard)

General Subscriber Hook-Problem:
- Those subscribers are not ordered. So I can imagine a scenario that 
other subscribers like to 'use' the object before it is initialized 
correctly (-> For example catalog indexes and unpolished object). So far 
we had no concerns with that fact.

(Addform example:
Its only a conceptual exampe for the tiks.typing resp. tiks.system 
framework that is basing on generic implementation that gets 
typed/classified only by a marker interface. But there you will see how 
you can handle the inialisation including addforms and addwizards:
(svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/demo/typing).)

If you (or anybody else) are interessest to use or to extend the 
framework, we could move the package to the zope repos too.

Regards,
Dominik




More information about the Zope3-dev mailing list