November 2004 - Zope-Dev

Patch for attribute permisions problems in Zope 2.7.3
by Santi Camps 21 Feb '05

21 Feb '05

Hi all again, We have been written last week about some attribute permission problems with Zope 2.7.3 beta due to a patch applied by Tres. First of all, Tres, apologies for my too fast written test case and my too late test of Zope 2.7.3. Now, with some more time, I've tested and debugged on Zope 2.7.3 and found exactly what's happen. Supose we have a structure of objects like this: A.__of__(B) "A" inherits from Acquisition.Implicit, has security assertions, but has not __allow_access_to_unprotected_subojects__ We want to access, from a Zope Page Template, an attribute of "B" that is not present in "A" Accessing B.our_attribute attribute works fine. But accessing A.__of__(B).our_attribute fails, and should work. The problem is the call to "validate" done in "guarded_getattr" method of ImplPython.py. The actual call is "if validate(inst, inst, name, v)", but the validate function says: Arguments: accessed -- the object that was being accessed container -- the object the value was found in name -- The name used to access the value value -- The value retrieved though the access. roles -- The roles of the object if already known. Now, "accessed" and "container" are always the same, and in some cases should be different. I attach a patch to solve this case that works for me. I'm not sure if my code is the best way to solve the problem but, as I said, it seems to work fine. Of course, If the patch is accepted, the same change should be done in the C version. Thanks Santi Camps http://www.earcon.com --- ImplPython.py 2004-08-07 19:15:48.000000000 +0200 +++ /usr/local/zope273/lib/python/AccessControl/ImplPython.py 2004-10-29 10:56:11.000000000 +0200 @@ -534,6 +534,12 @@ # exceptions are caught early. try: v = getattr(inst, name) + container = inst + while hasattr(container,'aq_explicit') and \ + not(hasattr(container.aq_explicit, name)) and \ + hasattr(container, 'aq_parent'): + # Find real container when attribute is acquired + container = container.aq_parent except AttributeError: if default is not _marker: return default @@ -551,6 +557,6 @@ return v validate = SecurityManagement.getSecurityManager().validate - if validate(inst, inst, name, v): + if validate(inst, container, name, v): return v raise Unauthorized, name

2 2

Why third_party/docutils?
by Stefan H. Holek 20 Dec '04

20 Dec '04

[docutils was moved from lib/python/docutils to lib/python/third_party/docutils/docutils and an ugly sys.path hack employed] Why oh why do we always have to make it harder to start up Zope (instead of making it simpler, for once)? Extending the path in lib/python/sitecustomize only works if lib/python is on the PYTHONPATH at the time the interpreter is started. This is fine in case of ./bin/zopectl, but not anywhere else. For example it breaks basically all test runners. Yes, I have seen that test.py got hacked to append third_party/docutils to the sys.path, this is however not a solution IMO, but plain cheating around a code layout error. test.py is *not* the only test runner around, nor is ./bin/zopectl the only way to start up Zope! Many a sysadmin will curse at having to "fix" a whole bunch of scripts. We have been very careful in the past to accommodate them, let me remind you of the ZOPE_CONFIG hack we added just for legacy scripts. What is the reason for third_party? Is is absolutely required, and if yes, why? Why not keep it simple (well, as simple as possible given the already tricky Z2 startup sequence)? I'd be very happy if this decision could be reconsidered. Thoughts? Stefan -- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/

7 22

permission management behaviour
by bTurtle ZOpe 03 Dec '04

03 Dec '04

Hi in a product I am working on, I have to set the permissions. I tried this, using the following code snippet: roles = object.valid_roles() object.manage_acquiredPermissions(permissions['Acquire']) for role in roles: object.manage_role(role, permissions[role]) permissions is a dictionary of roles with lists of permission names (e.g. {'Authenticated': [], 'Acquire': ['Access Transient Objects', 'Access arbitrary user session data', ...}). The thing I don't understand concerns the 'Manager' role. I observed the following things: - if I ommit the call to manage_acquiredPermissions, the permissions for 'Manager' are not set - 'Manager' inherits all permissions of Roles that are set AFTER the 'Manager' role is set (with manage_role). e.g. 'Owner' has the 'Add Database Methods' permission set. When the 'Owner' role is managed, the Permission 'Add Database Methods' is also added to the 'Manager' role. ('Owner' comes after 'Manager' in the roles list). Can someone explain why this is so? or what I am doing wrong. my setup is: Zope Version (unreleased version, python 2.3.3, linux2) Python Version 2.3.3 (#1, Apr 6 2004, 01:47:39) [GCC 3.3.3 (SuSE Linux)] regards Stefan

3 3

CatalogBrains.getObject and unrestricted code
by Florent Guillaume 29 Nov '04

29 Nov '04

In ZCatalog's brains, getObject currently does a restrictedTraverse to get the object. That's a problem for unrestricted code that needs to get to the object nevertheless, even if the user cannot get to it. For instance CMF is impacted, when it tries to reindex the security of all subobjects of a given object. Unless someone is opposed to it, I'll add a _getObject method that does an unrestrictedTraverse, and make CMF use it if available. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

3 3

including docutils in Zope -- two issues: IP and location
by Jim Fulton 29 Nov '04

29 Nov '04

I can understand the desire to include docutils in Zope. We made this decision for Zope 3 a while ago. Such a decision needs to be made *very* carefully for intellectual property reasons. Contributors other than Zope Corporation employees can only check in *their* code. This is important to reduce the risk of an IP problem. This means, unfortunatelky, that third-party code puts a burden on Zope Corporation, and thus, the community, since we become a bottle neck. Whatever we do with distutils, we have to make sure that Zope Corporation is involved and that ZC employees check in any code changes. (I assume that Andreas was a ZC employee when this code was originally checked in.) WRT location, I'd like to keep things as simple as possible. Top-level packages in the Zope 2 tree should be in lib/python. This is what was done for Zope 3 and it has worked well. Andreas, I'd be happy to sort this out with you off line if you like. Perhaps we can do with Zope 2 what we did for Zope 3, and, for Zope 2.8, perhaps we can even share the same tree. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

1 0

Removing XML export from Zope 2.8
by Andreas Jung 26 Nov '04

26 Nov '04

Any objects to kick the XML export from Zope 2.8 entirely? This feature is broken since ages and no one cares about it or is able/willing to fix it. It does not seem in use by anyone and it appears to me as a very useless feature. Any comments? Andreas

6 9

Making Role.py's __ac_local_roles__ play nicely with computed attributes
by Christian Theune 25 Nov '04

25 Nov '04

Hi, we currently have a project where we calculate local roles dynamically. This involves using a computed attribute as an __ac_local_roles__ replacement. Unfortunately this doesn't mix too well with assigning them manually, although our computed attribute takes care. Why is this and what can we do against that? __ac_local_roles__ is a dict. It's not a PersistentDictionary, but an ordinary Python dict. Therefore, to obey the rules of persistence, the Role.py local role machinery reassigns __ac_local_roles__ after every change. I'd like to change this, so that Role.py sets _p_changed instead, which is what it tries to signal. Additionally you need to explicitly assign __ac_local_roles__ instead of just getting dict=self.__ac_local_roles__ or {} so this becomes dict=self.__ac_local_roles__ if dict is None: self.__ac_local_roles = dict = {} This change works without disrupting the unit tests and I would love to get it on Zope 2.8. Any objections? I take silence as a 'no objections'. Cheers, Christian -- gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - ct(a)gocept.com - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development

2 1

Zope Community Contentment (Part II)
by Stephan Richter 23 Nov '04

23 Nov '04

Hi everyone, a while back Katrin Wodzicki (Katrin.Wodzicki_at_uni-jena.de) conducted a poll about the contentment of the Zope community. She has now prepared a second questionnaire that is based on the answers from the first one. This questionnaire is pretty short and I filled it out in about 10 minutes (since I wrote a lot -- most people will need only 5 minutes). The questionnaire is available bi-lingual in German and English at http://evaluation.gocept.com until December 5. Please take a moment to fill out the forms. It will help not only Katrin to finish her Diploma (German College degree), but also the Zope Community to better understand our community's strongholds and shortcommings. The results will be presented at the Sprint DZUG meeting and will be available afterwards online. So please, hit the server with some traffic! Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training

1 0

[Caching] Inefficient HTML cache?
by Dieter Maurer 23 Nov '04

23 Nov '04

We use Apache for caching and observe the following behaviour: Apache requests the object from Zope and caches it until the expiration date is reached. From then on, Apache forwards "If-Modified-Since" requests to Zope, Zope responds with an "304" response but without a new expiration date! As Apache does not get new expiration info, it continues to forward "If-Modified-Since" requests for the object. This significantly reduces cache efficiency. In my view, Zope should include new expiration info in its "304" responses. The CachingManager API may need to be extended, to allow the HTTP CacheManager to add information to "304" responses. -- Dieter

2 2

Re: [Zope-Checkins] CVS: Zope - test.py:1.2.2.16
by Stefan H. Holek 22 Nov '04

22 Nov '04

Sorry Florent, I missed your warning mail. I have two issues with the patch: a) Trailing slash no longer works (--libdir Products/) b) Some combinations of --libdir and --dir and symlinks no longer work on Mac OS X (HFS) Unfortunately os.getcwd() returns different paths in the presence of symlinks on Mac and Linux (already realpath'd vs not). I don't have a good solution for this either. You have a Mac haven't you? Does it work for you across all platforms? Thanks, Stefan On 19. Nov 2004, at 14:49, Florent Guillaume wrote: > Update of /cvs-repository/Zope > In directory cvs.zope.org:/tmp/cvs-serv20719 > > Modified Files: > Tag: Zope-2_7-branch > test.py > Log Message: > Fixed to work in the presence of symliked products or Products > directory. > > > === Zope/test.py 1.2.2.15 => 1.2.2.16 === > --- Zope/test.py:1.2.2.15 Sat Oct 30 04:29:22 2004 > +++ Zope/test.py Fri Nov 19 08:48:59 2004 > @@ -380,11 +380,12 @@ > self.cwd = os.path.realpath(os.getcwd()) > # Hack again for external products. > if libdir: > - self.libdir = os.path.realpath(os.path.join(self.cwd, > libdir)) > + self.libdir = os.path.join(self.cwd, libdir) > else: > - self.libdir = os.path.realpath(os.path.join(self.cwd, > self.libdir)) > - if self.libdir not in sys.path: > - sys.path.insert(0, self.libdir) > + self.libdir = os.path.join(self.cwd, self.libdir) > + real_libdir = os.path.realpath(self.libdir) > + if real_libdir not in sys.path: > + sys.path.insert(0, real_libdir) > # Determine where to look for tests > if test_dir: > self.testdir = os.path.abspath(os.path.join(self.cwd, > test_dir)) > > _______________________________________________ > Zope-Checkins maillist - Zope-Checkins(a)zope.org > http://mail.zope.org/mailman/listinfo/zope-checkins > -- The time has come to start talking about whether the emperor is as well dressed as we are supposed to think he is. /Pete McBreen/

2 2