Hi,
within the certification we once created a list (drawn from the CC
catalogue) of functionality we want to support.
One of those is called Residual Information Protection (RIP)
The meaning of RIP is that when you delete security attributes (roles,
users, groups, permission grants/denials)
Christian Theune wrote:
Hi,
within the certification we once created a list (drawn from the CC
catalogue) of functionality we want to support.
One of those is called Residual Information Protection (RIP)
The meaning of RIP is that when you delete security attributes (roles,
users, groups,
Hi,
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*
Jim Fulton wrote:
...
If we
need to be able to do this, we should design support into the
authorization system that we certify.
I'll note that this implies that the grants are stored centrally.
There are a number of reasons why this might be beneficial.
It's interesting to note that on Unix
Hi,
Am Freitag, den 16.12.2005, 07:49 -0500 schrieb Jim Fulton:
Christian Theune wrote:
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
Christian Theune wrote:
Hi,
Am Freitag, den 16.12.2005, 07:49 -0500 schrieb Jim Fulton:
Christian Theune wrote:
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
