[Zope-dev] Some apparent limitations of the Zope security model
Ross Boylan
RossBoylan@stanfordalumni.org
Thu, 06 Jan 2000 21:35:09 -0800
For some work I am doing I need to have a security model, and my initial
take is that Zope's security model will not meet my requirements. So I
should just implement my own, and bypass Zope's. I'd like to throw this
out for discussion, since I could be overlooking something, or this could
be a useful comment on the security model.
My decision is driven by 3 concerns, 2 of which are fundamental to the
architecture.
1) The concept of ownership I have seems different from Zope's. If I have
a person object P with a part A, I want the owner of part A to be P. But I
believe that the owner of A will in fact be whoever created A. So if an
administrator, or an administrative program, creates A, the "owner" of A is
the administrator.
Obviously my premise is that I want some access controlled by person,
rather than some larger group.
2) Also, I have some permissioning that I want to do in a way broader than
person, but more narrow than a particular role I would think appropriate to
create in Zope. Specifically, several people may be in the same family. I
want the family to have certain access rights (not the same as those for an
individual family member).
This is easy to implement in code, but does not seem to fit the Zope
security model. The only thing I can think of would be to create named
family roles on the fly ("familySimpson", "familyFlintsone", etc)
but--even if name collisions were finessed--this seems ugly. I also have
my doubts that the Zope permission model would work will with the many
roles such a scheme would produce.
The 3rd reason is practical, rather than fundamental:
3) If I do it myself, I don't have to worry about getting my classes, which
I may want to do as simply python objects, to play in the somewhat hard to
grasp Zope framework.
I welcome comments.