Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:

Roger Ineichen wrote:

[Martijn goes into why this might be slow]


Yes you are right. Do you have another idea?


A fairly drastic one, unfortunately -- catalog all role and permission
assignments and run a query as soon a user is removed.


CMF does this for local roles, and Jim is already on record as disliking
it.

I am pleased with the *result*, which also allows the catalog to filter
"normal" content results efficiently based on the user's roles (the
original eason for the index).  OTOH, the *implementation* is grotty.

I don't like the use case very much, but accept that it is valid.
You convinced me one day that this doesn't have to be so bad, especially
if most grants are to groups/roles.  (I've abandoned using roles as a principal
grouping mechanism, but that's a different topic.)

In any case, that's a different data structure than what we need here.

Here, I think the best solution is for the authorization system to store
grants in a centralized data structure of it's own.  This data structure
would be optimized for it's own purposes, not for document searching.
These two use cases want different data structures.


Hm, perhaps another idea would involve the timestamp of creation in the
userid somewhere, to make the ids unique. Unfortunately I don't see how
that would work with external authentication systems such as LDAP, as we
don't know when userids are created and removed there.


The actual ID used by LDAP is a DSN.  Perhaps the authorization system
could map the DSNs to internally-generated integer ID, which would be
the only value actually stored in grant records.

Isn't a dsn a string?  That's all we require of a principal id. What
advantage would an integer provide?

In any case, we are left with a more basic problems:

- Someone could be removed from an external user source without
  Zope being aware of it.

- An external system could remove a principal and reused the
  id for a new principal -- again without Zope being aware of it.

Jim

--
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
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to