Toby Dickenson wrote:
> 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.
Yeah, I think I get it now *grumble* *grumble* ;-)
> > 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.
Anyone know what those attributes are?
Maybe someone could knock up a new class in Acquisiton:
Acquisition.SecurityAcquire which does this but is like
Acquisition.Explicit for everything else?
>
> 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.
Yeah, I know :-S
But these are very specific classes that exist for no longer than the
duration of serving a single page request, and it'd just be nice to know
that they're not going to acquire and fluff they shouldn't...
cheers,
Chris
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
