[Zope-dev] zope-tests - FAILED: 2, OK: 39
This is the summary for test reports received on the zope-tests list between 2011-12-28 00:00:00 UTC and 2011-12-29 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit [1]ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 [2]Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux Non-OK results -- [1]FAILED ZTK 1.1dev / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-December/054973.html [2]FAILED Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2011-December/055000.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZopeSecurityPolicy global manipulation
Hi, AccessControl.ZopeSecurityPolicy contains this code: from types import MethodType # AccessControl.Implementation inserts: # ZopeSecurityPolicy, getRoles, rolesForPermissionOn from AccessControl.SimpleObjectPolicies import _noroles rolesForPermissionOn = None # XXX: avoid import loop tuple_or_list = tuple, list def getRoles(container, name, value, default): global rolesForPermissionOn # XXX: avoid import loop if rolesForPermissionOn is None: from PermissionRole import rolesForPermissionOn roles = getattr(value, '__roles__', _noroles) if roles is _noroles: if not name or not isinstance(name, basestring): return default if type(value) is MethodType: container = value.im_self cls = getattr(container, '__class__', None) if cls is None: return default roles = getattr(cls, name+'__roles__', _noroles) if roles is _noroles: return default value = container if roles is None or isinstance(roles, tuple_or_list): return roles rolesForPermissionOn = getattr(roles, 'rolesForPermissionOn', None) if rolesForPermissionOn is not None: roles = rolesForPermissionOn(value) return roles Look carefully at how ``rolesForPermissionOn`` is used both at the top, to lazily set a global to avoid an import loop, and the bottom, as an attribute of the ``roles`` object. I'm pretty sure this is wrong™ on many levels, but most importantly, it seems the global is being overwritten each time execution gets down to that last block. I know this module gets munged by Implementation, but I'm pretty sure ImplPython doesn't define getRoles() at least, and I'm not even sure the C implementation does either. To prove it to myself, I made a frivolous equivalent that used 'datetime.date' as the importable. It's a bit ugly, but you get the idea: >>> date = None >>> class C(object): ... def __init__(self, d): ... self.date = d ... >>> c1 = C(lambda: 'x') >>> c2 = C(lambda: 'y') >>> def get(c): ... global date ... if date is None: ... from datetime import date ... date = getattr(c, 'date', None) ... if date is not None: ... print date() ... >>> date is None True >>> get(c1) x >>> date at 0x10dac8140> >>> get(c2) y >>> date at 0x10dac8cf8> >>> Surely, this is all evil volatile? Maybe the global bit just needs to go away? It doesn't seem to be used in that function, and I'm pretty sure the implementation ends up overwriting the global anyway. Cheers, Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] PAS and AccessControl bug?
Hi, I found this code in PAS, which is mostly lifted from AccessControl.userfolder: def _getObjectContext( self, v, request ): """ request -> ( a, c, n, v ) o 'a 'is the object the object was accessed through o 'c 'is the physical container of the object o 'n 'is the name used to access the object o 'v' is the object (value) we're validating access to o XXX: Lifted from AccessControl.User.BasicUserFolder._getobcontext """ if len( request.steps ) == 0: # someone deleted root index_html request[ 'RESPONSE' ].notFoundError( 'no default view (root default view was probably deleted)' ) root = request[ 'PARENTS' ][ -1 ] request_container = aq_parent( root ) n = request.steps[ -1 ] # default to accessed and container as v.aq_parent a = c = request[ 'PARENTS' ][ 0 ] # try to find actual container inner = aq_inner( v ) innerparent = aq_parent( inner ) if innerparent is not None: # this is not a method, we needn't treat it specially c = innerparent elif hasattr(v, 'im_self'): # this is a method, we need to treat it specially c = v.im_self c = aq_inner( v ) # if pub's aq_parent or container is the request container, it # means pub was accessed from the root if a is request_container: a = root if c is request_container: c = root return a, c, n, v Look at this bit again: elif hasattr(v, 'im_self'): # this is a method, we need to treat it specially c = v.im_self c = aq_inner( v ) In AccessControl, it's similar: elif hasattr(v, 'im_self'): # this is a method, we need to treat it specially c = v.im_self c = getattr(v, 'aq_inner', v) Surely, this isn't right? What is the correct thing to do here? Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )