Jim Fulton wrote at 2003-11-13 15:22 -0500:
> We need to refactor the way security assertions (permission
> settings) are stored and accessed. We need to store required
> permissions (__permissions__) on objects. When we need to figure
> out roles, we need to compute them at a higher level. (For
> example, we could compute the needed roles in the zope security
> policy It's likely that we can speed security checks when doing
> I estimate that the necessary refactoring would take me 3-5
> days. The vast majority of the required time will be spent writing
> tests. I really need to focus on Zope 3 for a while, so I may not
> be able to get back to this soon. I think that this is an area
> where some volunteers could make a big difference. I'd be happy to
> work with some folks on this.
Folklore says that Zope cannot protect attributes of simple types
(because they do not provide the method magic that will be lost
However, whenever I looked at ZopeSecurityPolicy (and I did often),
I could not believe that this is true. I always thought, it would
be easy to provide security declarations for simple type attributes, too.
Of course, Zope cannot check a bare value of simple type, but
usually it has "container" and/or "parent" and then checking would
be easy by looking at related ("__roles__") attributes of the container/parent.
I will see this weekend whether I have been true.
If so, the same mechanism could (in principle) be used for
Bound methods can even be checked without "container/parent"
as they allow access to the bound instance.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -