[ZDP] BackTalk to Document Zope Developer's Guide (2.4 edition)/Security
Thu, 22 Aug 2002 04:04:32 -0400
A comment to the paragraph below was recently added via http://www.zope.org/Documentation/Books/ZDG/current/Security.stx#2-53
Zope security is based upon roles and permissions. Users have
roles. Security policies map permissions to roles. Classes
protect methods with permissions. As a developer you main job is
to protect your classes by associating methods with
permissions. Of course there are many other details such as
protecting modules and functions, creating security user
interfaces, and initializing security settings.
% Anonymous User - Jan. 4, 2002 4:14 pm - This from Dieter Maurer -- The basic security mechanism uses the attribute "m__roles__" in order to protect "m". If this attribute it "None", then "m" is public. Otherwise, it is expected to be a sequence of roles that are allowed to use "m". But, "ExtensionsClass" brings with it computed attributes. This allows "m__roles__" to be not a sequence but a method returning a sequence. When you protect "m" with a permission "p", then "m__roles__" is set to "PermissionRole(p)". This instance dynamically evaluates into a sequence of roles by crawling up the "aq_container" (which is correctly "aq_parent" after "aq_inner") chain and translating "p" into roles by interpreting the "permission-to-role" mapping it finds on its way to the application object. Therefore, "declarePublic" works for non-wrapped instances while "declareProtected" requires the wrapping.
% Anonymous User - May 3, 2002 4:47 am:
From Julian Munoz -- I don't find any reference to security and object properties.
% d.maurer - Aug. 22, 2002 4:04 am:
I would like to learn details about __guarded_getattr__,
__guarded_setattr__ and friends.
What is their semantics?
Are they expected to do their own security checks (I
expect a "yes" to this question)?
Is it usually safe to implement "__guarded_getattr__"
if not getSecurityManager().validate(accessed=self,
raise 'Unauthorized', attr