[Zope-dev] RE: Security requires Acquisition?!

[Toby Dickenson]

> Okay, this did the trick, but I'm not very happy with the result :-(
> 
> I don't want the DisplayClass to be acquiring and I don't really see
> (from a moral standpoint ;-) why I should need to mix in an Acquisiton
> class to make security work :-S

I suspect that was a rhetorical question, but ill answer anyway.

Zope security is context based: Users can be defined in a subfolder and only
have access under that folder, they can also be given local roles for a
given folder. The role:permission mapping is set per-folder. Any security
aware object needs to know its context.

> That said, I think Shane said that Zope security is 
> predicated a lot on
> Acquisition. Now, can I get the solution I'm looking for by mixing in
> Aquisition.Explicit, still have the security stuff work and 
> not have the
> DisplayClass acquiring attributes I don't want it do?

Yes, you will need to set Acquisition.Acquired for the necessary attributes.

Alternatively there may be other ways of avoiding an object using some
specific acquired attributes: I often define an index_html=None to avoid a
class using its container's default view.

Wanting to make an object non-acquiring may be a danger-sign of some other
problems. If the correctness of your program depends on the absence of
certain attributes (acquired or otherwise) then you need to take extra care
over PropertyManager-like features, which might allow a user to add the
critical attribute.

hth,