Some apparent limitations of the Zope security model
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.
participants (1)
-
Ross Boylan