Christian Theune wrote:
Am Freitag, den 16.12.2005, 07:16 -0500 schrieb Jim Fulton:
This is only a problem if username === user id. In both Zope 2 and
Zope 3, these are distinct, although this isn't widely recognized or
leveraged in Zope 2. I don't think it is necessary to remove all
grants to an old user *id* as long as ids are never reused. I'd say it
might even be useful to keep the old grants, at least for some period,
for auditing purposed.
If we *do* need to be able to remove all grants for a deleted user
when we remove a user, then we need to provide an authorization system
that makes this possible.
I think if we can guarantee never to reuse a user id, provide a tool for
doing RIP and we do not provide undo we are fine.
Only if we manage the user ids. We often get principal ids from outside
sources. In fact, we usually do this in production. In the case when
we're using an external principal soure, we also don't autmatically
know when the principal is removed.
Also, current principal-management facilities in Zope 3 allow managers to
pick ids. We probably would need to curtail this or at least prevent
It's probably not wise to rely on this.
By definition, there is no efficient way to iterate over all objects
in a database, any database, unless the database is small. If we
need to be able to do this, we should design support into the
authorization system that we certify.
Agreed. This would mean that the authorization system (which is policy
dependant if I understand it correctly) will have to maintain data
structures that allow efficient handling for those tasks. Right?
Right. The security policy is part of the authorization system.
The authorization system, or at least a CC-complient authorization
system should probably grow a principal-removal API.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list