[Zope-Checkins] SVN: Zope/branches/2.9/lib/python/AccessControl/ Fixed problem with security.setPermissionDefault when the permission
Log message for revision 40403:
Fixed problem with security.setPermissionDefault when the permission
wasn't used anywhere else in the class to protect methods.
Changed:
U Zope/branches/2.9/lib/python/AccessControl/SecurityInfo.py
U Zope/branches/2.9/lib/python/AccessControl/tests/testClassSecurityInfo.py
-=-
Modified: Zope/branches/2.9/lib/python/AccessControl/SecurityInfo.py
===
--- Zope/branches/2.9/lib/python/AccessControl/SecurityInfo.py 2005-11-29
14:30:14 UTC (rev 40402)
+++ Zope/branches/2.9/lib/python/AccessControl/SecurityInfo.py 2005-11-29
14:54:15 UTC (rev 40403)
@@ -180,6 +180,10 @@
else:
entry = (permission_name, tuple(names))
__ac_permissions__.append(entry)
+for permission_name, roles in self.roles.items():
+if permission_name not in ac_permissions:
+entry = (permission_name, (), tuple(roles.keys()))
+__ac_permissions__.append(entry)
setattr(classobj, '__ac_permissions__', tuple(__ac_permissions__))
# Take care of default attribute access policy
Modified:
Zope/branches/2.9/lib/python/AccessControl/tests/testClassSecurityInfo.py
===
--- Zope/branches/2.9/lib/python/AccessControl/tests/testClassSecurityInfo.py
2005-11-29 14:30:14 UTC (rev 40402)
+++ Zope/branches/2.9/lib/python/AccessControl/tests/testClassSecurityInfo.py
2005-11-29 14:54:15 UTC (rev 40403)
@@ -44,6 +44,8 @@
security = ClassSecurityInfo()
+security.setPermissionDefault('Make food', ('Chef',))
+
security.setPermissionDefault(
'Test permission',
('Manager', 'Role A', 'Role B', 'Role C')
@@ -68,7 +70,12 @@
for item in ('Manager', 'Role A', 'Role B', 'Role C'):
self.failUnless(item in imPermissionRole)
+# Make sure that a permission defined without accompanying method
+# is still reflected in __ac_permissions__
+self.assertEquals([t for t in Test.__ac_permissions__ if not t[1]],
+ [('Make food', (), ('Chef',))])
+
def test_suite():
suite = unittest.TestSuite()
suite.addTest(unittest.makeSuite(ClassSecurityInfoTests))
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/lib/python/AccessControl/ Merged r40403 from 2.9 branch:
Log message for revision 40404:
Merged r40403 from 2.9 branch:
Fixed problem with security.setPermissionDefault when the permission
wasn't used anywhere else in the class to protect methods.
Changed:
U Zope/trunk/lib/python/AccessControl/SecurityInfo.py
U Zope/trunk/lib/python/AccessControl/tests/testClassSecurityInfo.py
-=-
Modified: Zope/trunk/lib/python/AccessControl/SecurityInfo.py
===
--- Zope/trunk/lib/python/AccessControl/SecurityInfo.py 2005-11-29 14:54:15 UTC
(rev 40403)
+++ Zope/trunk/lib/python/AccessControl/SecurityInfo.py 2005-11-29 14:56:48 UTC
(rev 40404)
@@ -180,6 +180,10 @@
else:
entry = (permission_name, tuple(names))
__ac_permissions__.append(entry)
+for permission_name, roles in self.roles.items():
+if permission_name not in ac_permissions:
+entry = (permission_name, (), tuple(roles.keys()))
+__ac_permissions__.append(entry)
setattr(classobj, '__ac_permissions__', tuple(__ac_permissions__))
# Take care of default attribute access policy
Modified: Zope/trunk/lib/python/AccessControl/tests/testClassSecurityInfo.py
===
--- Zope/trunk/lib/python/AccessControl/tests/testClassSecurityInfo.py
2005-11-29 14:54:15 UTC (rev 40403)
+++ Zope/trunk/lib/python/AccessControl/tests/testClassSecurityInfo.py
2005-11-29 14:56:48 UTC (rev 40404)
@@ -44,6 +44,8 @@
security = ClassSecurityInfo()
+security.setPermissionDefault('Make food', ('Chef',))
+
security.setPermissionDefault(
'Test permission',
('Manager', 'Role A', 'Role B', 'Role C')
@@ -68,7 +70,12 @@
for item in ('Manager', 'Role A', 'Role B', 'Role C'):
self.failUnless(item in imPermissionRole)
+# Make sure that a permission defined without accompanying method
+# is still reflected in __ac_permissions__
+self.assertEquals([t for t in Test.__ac_permissions__ if not t[1]],
+ [('Make food', (), ('Chef',))])
+
def test_suite():
suite = unittest.TestSuite()
suite.addTest(unittest.makeSuite(ClassSecurityInfoTests))
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.9/doc/CHANGES.txt Update CHANGES.
Log message for revision 40405: Update CHANGES. Changed: U Zope/branches/2.9/doc/CHANGES.txt -=- Modified: Zope/branches/2.9/doc/CHANGES.txt === --- Zope/branches/2.9/doc/CHANGES.txt 2005-11-29 14:56:48 UTC (rev 40404) +++ Zope/branches/2.9/doc/CHANGES.txt 2005-11-29 15:03:04 UTC (rev 40405) @@ -95,6 +95,10 @@ Bugs Fixed + - AccessControl.SecurityInfo: Fixed problem with +setPermissionDefault when the permission wasn't used anywhere +else in the class to protect methods. + - OFS PropertySheets / webdav: Fixed dav__resourcetype. __dav_collection__ with a false value was overridden by isAnObjectManager. ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/ Merged r40403 from 2.9 branch:
Log message for revision 40406:
Merged r40403 from 2.9 branch:
Fixed problem with security.setPermissionDefault when the permission
wasn't used anywhere else in the class to protect methods.
Changed:
U Zope/branches/Zope-2_8-branch/doc/CHANGES.txt
U Zope/branches/Zope-2_8-branch/lib/python/AccessControl/SecurityInfo.py
U
Zope/branches/Zope-2_8-branch/lib/python/AccessControl/tests/testClassSecurityInfo.py
-=-
Modified: Zope/branches/Zope-2_8-branch/doc/CHANGES.txt
===
--- Zope/branches/Zope-2_8-branch/doc/CHANGES.txt 2005-11-29 15:03:04 UTC
(rev 40405)
+++ Zope/branches/Zope-2_8-branch/doc/CHANGES.txt 2005-11-29 15:05:15 UTC
(rev 40406)
@@ -26,6 +26,10 @@
Bugs Fixed
+ - AccessControl.SecurityInfo: Fixed problem with
+setPermissionDefault when the permission wasn't used anywhere
+else in the class to protect methods.
+
- Collector #1957: Made ZPublisher.HTTPResponse._error_html
return conformant XHTML.
Modified: Zope/branches/Zope-2_8-branch/lib/python/AccessControl/SecurityInfo.py
===
--- Zope/branches/Zope-2_8-branch/lib/python/AccessControl/SecurityInfo.py
2005-11-29 15:03:04 UTC (rev 40405)
+++ Zope/branches/Zope-2_8-branch/lib/python/AccessControl/SecurityInfo.py
2005-11-29 15:05:15 UTC (rev 40406)
@@ -180,6 +180,10 @@
else:
entry = (permission_name, tuple(names))
__ac_permissions__.append(entry)
+for permission_name, roles in self.roles.items():
+if permission_name not in ac_permissions:
+entry = (permission_name, (), tuple(roles.keys()))
+__ac_permissions__.append(entry)
setattr(classobj, '__ac_permissions__', tuple(__ac_permissions__))
# Take care of default attribute access policy
Modified:
Zope/branches/Zope-2_8-branch/lib/python/AccessControl/tests/testClassSecurityInfo.py
===
---
Zope/branches/Zope-2_8-branch/lib/python/AccessControl/tests/testClassSecurityInfo.py
2005-11-29 15:03:04 UTC (rev 40405)
+++
Zope/branches/Zope-2_8-branch/lib/python/AccessControl/tests/testClassSecurityInfo.py
2005-11-29 15:05:15 UTC (rev 40406)
@@ -44,6 +44,8 @@
security = ClassSecurityInfo()
+security.setPermissionDefault('Make food', ('Chef',))
+
security.setPermissionDefault(
'Test permission',
('Manager', 'Role A', 'Role B', 'Role C')
@@ -68,7 +70,12 @@
for item in ('Manager', 'Role A', 'Role B', 'Role C'):
self.failUnless(item in imPermissionRole)
+# Make sure that a permission defined without accompanying method
+# is still reflected in __ac_permissions__
+self.assertEquals([t for t in Test.__ac_permissions__ if not t[1]],
+ [('Make food', (), ('Chef',))])
+
def test_suite():
suite = unittest.TestSuite()
suite.addTest(unittest.makeSuite(ClassSecurityInfoTests))
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/lib/python/DateTime/DateTime.txt Fix timezone issues. I shoulda seen that one coming...
Log message for revision 40407:
Fix timezone issues. I shoulda seen that one coming...
Changed:
U Zope/trunk/lib/python/DateTime/DateTime.txt
-=-
Modified: Zope/trunk/lib/python/DateTime/DateTime.txt
===
--- Zope/trunk/lib/python/DateTime/DateTime.txt 2005-11-29 15:05:15 UTC (rev
40406)
+++ Zope/trunk/lib/python/DateTime/DateTime.txt 2005-11-29 15:25:58 UTC (rev
40407)
@@ -219,11 +219,11 @@
dt.timeTime()
857933100.0
- DateTime('2040/01/01').timeTime()
-2208985200.0
+ DateTime('2040/01/01 UTC').timeTime()
+2208988800.0
- DateTime('1900/01/01').timeTime()
--2208992400.0
+ DateTime('1900/01/01 UTC').timeTime()
+-2208988800.0
* ``toZone(z)`` returns a DateTime with the value as the current
object, represented in the indicated timezone:
___
Zope-Checkins maillist - Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/2.9/lib/python/OFS/ Added backward compat for suppress_events parameter passing.
Log message for revision 40408: Added backward compat for suppress_events parameter passing. Changed: U Zope/branches/2.9/lib/python/OFS/CopySupport.py U Zope/branches/2.9/lib/python/OFS/OrderSupport.py -=- Modified: Zope/branches/2.9/lib/python/OFS/CopySupport.py === --- Zope/branches/2.9/lib/python/OFS/CopySupport.py 2005-11-29 15:25:58 UTC (rev 40407) +++ Zope/branches/2.9/lib/python/OFS/CopySupport.py 2005-11-29 15:42:12 UTC (rev 40408) @@ -16,6 +16,7 @@ import re, sys, tempfile +import warnings from cgi import escape from marshal import loads, dumps from urllib import quote, unquote @@ -266,11 +267,27 @@ # along to the new location if needed. ob.manage_changeOwnershipType(explicit=1) -orig_container._delObject(orig_id, suppress_events=True) +try: +orig_container._delObject(orig_id, suppress_events=True) +except TypeError: +# BBB: removed in Zope 2.11 +orig_container._delObject(orig_id) +warnings.warn( +%s._delObject without suppress_events is deprecated +and will be removed in Zope 2.11. % +orig_container.__class__.__name__, DeprecationWarning) ob = aq_base(ob) ob._setId(id) -self._setObject(id, ob, set_owner=0, suppress_events=True) +try: +self._setObject(id, ob, set_owner=0, suppress_events=True) +except TypeError: +# BBB: removed in Zope 2.11 +self._setObject(id, ob, set_owner=0) +warnings.warn( +%s._setObject without suppress_events is deprecated +and will be removed in Zope 2.11. % +self.__class__.__name__, DeprecationWarning) ob = self._getOb(id) notify(ObjectMovedEvent(ob, orig_container, orig_id, self, id)) @@ -337,13 +354,29 @@ notify(ObjectWillBeMovedEvent(ob, self, id, self, new_id)) -self._delObject(id, suppress_events=True) +try: +self._delObject(id, suppress_events=True) +except TypeError: +# BBB: removed in Zope 2.11 +self._delObject(id) +warnings.warn( +%s._delObject without suppress_events is deprecated +and will be removed in Zope 2.11. % +self.__class__.__name__, DeprecationWarning) ob = aq_base(ob) ob._setId(new_id) # Note - because a rename always keeps the same context, we # can just leave the ownership info unchanged. -self._setObject(new_id, ob, set_owner=0, suppress_events=True) +try: +self._setObject(new_id, ob, set_owner=0, suppress_events=True) +except TypeError: +# BBB: removed in Zope 2.11 +self._setObject(new_id, ob, set_owner=0) +warnings.warn( +%s._setObject without suppress_events is deprecated +and will be removed in Zope 2.11. % +self.__class__.__name__, DeprecationWarning) ob = self._getOb(new_id) notify(ObjectMovedEvent(ob, self, id, self, new_id)) Modified: Zope/branches/2.9/lib/python/OFS/OrderSupport.py === --- Zope/branches/2.9/lib/python/OFS/OrderSupport.py2005-11-29 15:25:58 UTC (rev 40407) +++ Zope/branches/2.9/lib/python/OFS/OrderSupport.py2005-11-29 15:42:12 UTC (rev 40408) @@ -16,7 +16,7 @@ from types import StringType - +import warnings from AccessControl import ClassSecurityInfo from AccessControl.Permissions import access_contents_information from AccessControl.Permissions import manage_properties @@ -263,7 +263,16 @@ old_position = self.getObjectPosition(id) result = super(OrderSupport, self).manage_renameObject(id, new_id, REQUEST) -self.moveObjectToPosition(new_id, old_position, suppress_events=True) +try: +self.moveObjectToPosition(new_id, old_position, + suppress_events=True) +except TypeError: +# BBB: removed in Zope 2.11 +self.moveObjectToPosition(new_id, old_position) +warnings.warn( +%s.moveObjectToPosition without suppress_events is +deprecated and will be removed in Zope 2.11. % +self.__class__.__name__, DeprecationWarning) return result def tpValues(self): ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/trunk/lib/python/OFS/ Merged r40408 from 2.9 branch:
Log message for revision 40409: Merged r40408 from 2.9 branch: Added backward compat for suppress_events parameter passing. Changed: U Zope/trunk/lib/python/OFS/CopySupport.py U Zope/trunk/lib/python/OFS/OrderSupport.py -=- Modified: Zope/trunk/lib/python/OFS/CopySupport.py === --- Zope/trunk/lib/python/OFS/CopySupport.py2005-11-29 15:42:12 UTC (rev 40408) +++ Zope/trunk/lib/python/OFS/CopySupport.py2005-11-29 15:43:35 UTC (rev 40409) @@ -16,6 +16,7 @@ import re, sys, tempfile +import warnings from cgi import escape from marshal import loads, dumps from urllib import quote, unquote @@ -267,11 +268,27 @@ # along to the new location if needed. ob.manage_changeOwnershipType(explicit=1) -orig_container._delObject(orig_id, suppress_events=True) +try: +orig_container._delObject(orig_id, suppress_events=True) +except TypeError: +# BBB: removed in Zope 2.11 +orig_container._delObject(orig_id) +warnings.warn( +%s._delObject without suppress_events is deprecated +and will be removed in Zope 2.11. % +orig_container.__class__.__name__, DeprecationWarning) ob = aq_base(ob) ob._setId(id) -self._setObject(id, ob, set_owner=0, suppress_events=True) +try: +self._setObject(id, ob, set_owner=0, suppress_events=True) +except TypeError: +# BBB: removed in Zope 2.11 +self._setObject(id, ob, set_owner=0) +warnings.warn( +%s._setObject without suppress_events is deprecated +and will be removed in Zope 2.11. % +self.__class__.__name__, DeprecationWarning) ob = self._getOb(id) notify(ObjectMovedEvent(ob, orig_container, orig_id, self, id)) @@ -341,13 +358,29 @@ notify(ObjectWillBeMovedEvent(ob, self, id, self, new_id)) -self._delObject(id, suppress_events=True) +try: +self._delObject(id, suppress_events=True) +except TypeError: +# BBB: removed in Zope 2.11 +self._delObject(id) +warnings.warn( +%s._delObject without suppress_events is deprecated +and will be removed in Zope 2.11. % +self.__class__.__name__, DeprecationWarning) ob = aq_base(ob) ob._setId(new_id) # Note - because a rename always keeps the same context, we # can just leave the ownership info unchanged. -self._setObject(new_id, ob, set_owner=0, suppress_events=True) +try: +self._setObject(new_id, ob, set_owner=0, suppress_events=True) +except TypeError: +# BBB: removed in Zope 2.11 +self._setObject(new_id, ob, set_owner=0) +warnings.warn( +%s._setObject without suppress_events is deprecated +and will be removed in Zope 2.11. % +self.__class__.__name__, DeprecationWarning) ob = self._getOb(new_id) notify(ObjectMovedEvent(ob, self, id, self, new_id)) Modified: Zope/trunk/lib/python/OFS/OrderSupport.py === --- Zope/trunk/lib/python/OFS/OrderSupport.py 2005-11-29 15:42:12 UTC (rev 40408) +++ Zope/trunk/lib/python/OFS/OrderSupport.py 2005-11-29 15:43:35 UTC (rev 40409) @@ -16,7 +16,7 @@ from types import StringType - +import warnings from AccessControl import ClassSecurityInfo from AccessControl.Permissions import access_contents_information from AccessControl.Permissions import manage_properties @@ -263,7 +263,16 @@ old_position = self.getObjectPosition(id) result = super(OrderSupport, self).manage_renameObject(id, new_id, REQUEST) -self.moveObjectToPosition(new_id, old_position, suppress_events=True) +try: +self.moveObjectToPosition(new_id, old_position, + suppress_events=True) +except TypeError: +# BBB: removed in Zope 2.11 +self.moveObjectToPosition(new_id, old_position) +warnings.warn( +%s.moveObjectToPosition without suppress_events is +deprecated and will be removed in Zope 2.11. % +self.__class__.__name__, DeprecationWarning) return result def tpValues(self): ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/lib/python/AccessControl/ Add interface and tests for AccessControl.SecurityManager.
Log message for revision 40418:
Add interface and tests for AccessControl.SecurityManager.
o The new tests are amphibious: they exercise both the Python and the C
implementations, ensuring that they remain in sync.
Changed:
U Zope/branches/Zope-2_8-branch/lib/python/AccessControl/ImplPython.py
A Zope/branches/Zope-2_8-branch/lib/python/AccessControl/interfaces.py
A
Zope/branches/Zope-2_8-branch/lib/python/AccessControl/tests/testSecurityManager.py
-=-
Modified: Zope/branches/Zope-2_8-branch/lib/python/AccessControl/ImplPython.py
===
--- Zope/branches/Zope-2_8-branch/lib/python/AccessControl/ImplPython.py
2005-11-29 20:40:33 UTC (rev 40417)
+++ Zope/branches/Zope-2_8-branch/lib/python/AccessControl/ImplPython.py
2005-11-30 00:53:34 UTC (rev 40418)
@@ -22,6 +22,7 @@
from Acquisition import aq_acquire
from ExtensionClass import Base
from zLOG import LOG, BLATHER, PROBLEM
+from zope.interface import implements
# This is used when a permission maps explicitly to no permission. We
# try and get this from cAccessControl first to make sure that if both
@@ -33,6 +34,7 @@
from AccessControl import SecurityManagement
from AccessControl import Unauthorized
+from AccessControl.interfaces import ISecurityManager
from AccessControl.SimpleObjectPolicies import Containers, _noroles
from AccessControl.ZopeGuards import guarded_getitem
@@ -491,7 +493,7 @@
A security manager provides methods for checking access and managing
executable context and policies
-
+implements(ISecurityManager)
__allow_access_to_unprotected_subobjects__ = {
'validate': 1, 'checkPermission': 1,
'getUser': 1, 'calledByExecutable': 1
Added: Zope/branches/Zope-2_8-branch/lib/python/AccessControl/interfaces.py
===
--- Zope/branches/Zope-2_8-branch/lib/python/AccessControl/interfaces.py
2005-11-29 20:40:33 UTC (rev 40417)
+++ Zope/branches/Zope-2_8-branch/lib/python/AccessControl/interfaces.py
2005-11-30 00:53:34 UTC (rev 40418)
@@ -0,0 +1,119 @@
+##
+#
+# Copyright (c) 2005 Zope Corporation and Contributors. All Rights Reserved.
+#
+# This software is subject to the provisions of the Zope Public License,
+# Version 2.0 (ZPL). A copy of the ZPL should accompany this distribution.
+# THIS SOFTWARE IS PROVIDED AS IS AND ANY AND ALL EXPRESS OR IMPLIED
+# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
+# FOR A PARTICULAR PURPOSE
+#
+##
+Access control interfaces
+
+
+from AccessControl.SimpleObjectPolicies import _noroles
+from zope.interface import Interface
+from zope.interface import Attribute
+
+class ISecurityManager(Interface):
+Checks access and manages executable context and policies.
+
+_policy = Attribute(u'Current Security Policy')
+
+def validate(accessed=None,
+ container=None,
+ name=None,
+ value=None,
+ roles=_noroles,
+):
+Validate access.
+
+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.
+
+The arguments may be provided as keyword arguments. Some of these
+arguments may be ommitted, however, the policy may reject access
+in some cases when arguments are ommitted. It is best to provide
+all the values possible.
+
+
+def DTMLValidate(accessed=None,
+ container=None,
+ name=None,
+ value=None,
+ md=None,
+):
+Validate access.
+* THIS EXISTS FOR DTML COMPATIBILITY *
+
+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.
+
+md -- multidict for DTML (ignored)
+
+The arguments may be provided as keyword arguments. Some of these
+arguments may be ommitted, however, the policy may reject access
+in some cases when arguments are ommitted. It is best to provide
+all the values possible.
+
+
+
+def checkPermission(permission, object):
+Check whether the security context allows the given permission on
+the given object.
+
+Arguments:
+
+permission -- A permission name
+
+
[Zope-Checkins] SVN: Zope/branches/2.9/lib/python/AccessControl/ Add interface and tests for AccessControl.SecurityManager.
Log message for revision 40419:
Add interface and tests for AccessControl.SecurityManager.
o The new tests are amphibious: they exercise both the Python and the C
implementations, ensuring that they remain in sync.
Changed:
U Zope/branches/2.9/lib/python/AccessControl/ImplPython.py
U Zope/branches/2.9/lib/python/AccessControl/interfaces.py
A Zope/branches/2.9/lib/python/AccessControl/tests/testSecurityManager.py
-=-
Modified: Zope/branches/2.9/lib/python/AccessControl/ImplPython.py
===
--- Zope/branches/2.9/lib/python/AccessControl/ImplPython.py2005-11-30
00:53:34 UTC (rev 40418)
+++ Zope/branches/2.9/lib/python/AccessControl/ImplPython.py2005-11-30
00:55:24 UTC (rev 40419)
@@ -22,6 +22,7 @@
from Acquisition import aq_acquire
from ExtensionClass import Base
from zLOG import LOG, BLATHER, PROBLEM
+from zope.interface import implements
# This is used when a permission maps explicitly to no permission. We
# try and get this from cAccessControl first to make sure that if both
@@ -33,6 +34,7 @@
from AccessControl import SecurityManagement
from AccessControl import Unauthorized
+from AccessControl.interfaces import ISecurityManager
from AccessControl.SimpleObjectPolicies import Containers, _noroles
from AccessControl.ZopeGuards import guarded_getitem
@@ -491,7 +493,7 @@
A security manager provides methods for checking access and managing
executable context and policies
-
+implements(ISecurityManager)
__allow_access_to_unprotected_subobjects__ = {
'validate': 1, 'checkPermission': 1,
'getUser': 1, 'calledByExecutable': 1
Modified: Zope/branches/2.9/lib/python/AccessControl/interfaces.py
===
--- Zope/branches/2.9/lib/python/AccessControl/interfaces.py2005-11-30
00:53:34 UTC (rev 40418)
+++ Zope/branches/2.9/lib/python/AccessControl/interfaces.py2005-11-30
00:55:24 UTC (rev 40419)
@@ -15,6 +15,7 @@
$Id$
+from AccessControl.SimpleObjectPolicies import _noroles
from zope.interface import Attribute
from zope.interface import Interface
@@ -280,3 +281,104 @@
def getUserNames():
Get a sequence of names of the users which reside in the user
folder.
+
+class ISecurityManager(Interface):
+Checks access and manages executable context and policies.
+
+_policy = Attribute(u'Current Security Policy')
+
+def validate(accessed=None,
+ container=None,
+ name=None,
+ value=None,
+ roles=_noroles,
+):
+Validate access.
+
+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.
+
+The arguments may be provided as keyword arguments. Some of these
+arguments may be ommitted, however, the policy may reject access
+in some cases when arguments are ommitted. It is best to provide
+all the values possible.
+
+
+def DTMLValidate(accessed=None,
+ container=None,
+ name=None,
+ value=None,
+ md=None,
+):
+Validate access.
+* THIS EXISTS FOR DTML COMPATIBILITY *
+
+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.
+
+md -- multidict for DTML (ignored)
+
+The arguments may be provided as keyword arguments. Some of these
+arguments may be ommitted, however, the policy may reject access
+in some cases when arguments are ommitted. It is best to provide
+all the values possible.
+
+
+
+def checkPermission(permission, object):
+Check whether the security context allows the given permission on
+the given object.
+
+Arguments:
+
+permission -- A permission name
+
+object -- The object being accessed according to the permission
+
+
+def addContext(anExecutableObject):
+Add an ExecutableObject to the current security context.
+
+o If it declares a custom security policy, make that policy
+ current; otherwise, make the default security policy
+ current.
+
+
+def removeContext(anExecutableObject):
+Remove an ExecutableObject from the current security context.
+
+o Remove all objects from the top of the stack down to the
+ supplied object.
+
+o If the top object on the stack declares a
[Zope-Checkins] SVN: Zope/trunk/lib/python/AccessControl/ Add interface and tests for AccessControl.SecurityManager.
Log message for revision 40420:
Add interface and tests for AccessControl.SecurityManager.
o The new tests are amphibious: they exercise both the Python and the C
implementations, ensuring that they remain in sync.
Changed:
U Zope/trunk/lib/python/AccessControl/ImplPython.py
U Zope/trunk/lib/python/AccessControl/interfaces.py
A Zope/trunk/lib/python/AccessControl/tests/testSecurityManager.py
-=-
Modified: Zope/trunk/lib/python/AccessControl/ImplPython.py
===
--- Zope/trunk/lib/python/AccessControl/ImplPython.py 2005-11-30 00:55:24 UTC
(rev 40419)
+++ Zope/trunk/lib/python/AccessControl/ImplPython.py 2005-11-30 03:40:57 UTC
(rev 40420)
@@ -22,6 +22,7 @@
from Acquisition import aq_acquire
from ExtensionClass import Base
from zLOG import LOG, BLATHER, PROBLEM
+from zope.interface import implements
# This is used when a permission maps explicitly to no permission. We
# try and get this from cAccessControl first to make sure that if both
@@ -33,6 +34,7 @@
from AccessControl import SecurityManagement
from AccessControl import Unauthorized
+from AccessControl.interfaces import ISecurityManager
from AccessControl.SimpleObjectPolicies import Containers, _noroles
from AccessControl.ZopeGuards import guarded_getitem
@@ -491,7 +493,7 @@
A security manager provides methods for checking access and managing
executable context and policies
-
+implements(ISecurityManager)
__allow_access_to_unprotected_subobjects__ = {
'validate': 1, 'checkPermission': 1,
'getUser': 1, 'calledByExecutable': 1
Modified: Zope/trunk/lib/python/AccessControl/interfaces.py
===
--- Zope/trunk/lib/python/AccessControl/interfaces.py 2005-11-30 00:55:24 UTC
(rev 40419)
+++ Zope/trunk/lib/python/AccessControl/interfaces.py 2005-11-30 03:40:57 UTC
(rev 40420)
@@ -15,6 +15,7 @@
$Id$
+from AccessControl.SimpleObjectPolicies import _noroles
from zope.interface import Attribute
from zope.interface import Interface
@@ -280,3 +281,104 @@
def getUserNames():
Get a sequence of names of the users which reside in the user
folder.
+
+class ISecurityManager(Interface):
+Checks access and manages executable context and policies.
+
+_policy = Attribute(u'Current Security Policy')
+
+def validate(accessed=None,
+ container=None,
+ name=None,
+ value=None,
+ roles=_noroles,
+):
+Validate access.
+
+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.
+
+The arguments may be provided as keyword arguments. Some of these
+arguments may be ommitted, however, the policy may reject access
+in some cases when arguments are ommitted. It is best to provide
+all the values possible.
+
+
+def DTMLValidate(accessed=None,
+ container=None,
+ name=None,
+ value=None,
+ md=None,
+):
+Validate access.
+* THIS EXISTS FOR DTML COMPATIBILITY *
+
+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.
+
+md -- multidict for DTML (ignored)
+
+The arguments may be provided as keyword arguments. Some of these
+arguments may be ommitted, however, the policy may reject access
+in some cases when arguments are ommitted. It is best to provide
+all the values possible.
+
+
+
+def checkPermission(permission, object):
+Check whether the security context allows the given permission on
+the given object.
+
+Arguments:
+
+permission -- A permission name
+
+object -- The object being accessed according to the permission
+
+
+def addContext(anExecutableObject):
+Add an ExecutableObject to the current security context.
+
+o If it declares a custom security policy, make that policy
+ current; otherwise, make the default security policy
+ current.
+
+
+def removeContext(anExecutableObject):
+Remove an ExecutableObject from the current security context.
+
+o Remove all objects from the top of the stack down to the
+ supplied object.
+
+o If the top object on the stack declares a custom security policy,
+ make that policy current.
+
+
[Zope-dev] Re: DateTime mess
Tres Seaver wrote: Philipp von Weitershausen wrote: Andrew Milton wrote: -1 for any scheme that involves diddling the ZODB to 'fix' pickles, because you just know you're going to corrupt someone's ZODB, and that's just noone's idea of fun. There are sensible ways of upgrading the ZODB. Zope 3 has had it since 3.0 (called generations) and they've been working reasonably well for these things. They aren't well-enough battle tested to make Andrew's point invalid, I think (there *are* no large ZODB-based Zope3 sites which have undergone generational upgrades). Frankly, anything which attempts to fix pickles in-place smells bad to me. Dump and reload is how the RDBMS world handles this kind of problem, and it isn't because they don't have smart folks working on them. You're right, as nice as generations might be, they can't work around some of the architectural flaws of the ZODB. And, of course, they've not been battle tested, but who's going to battle test them until they are battle tested? Chicken... egg... :). So, do I take it that you're suggesting the upgrade strategy should entail some sort of dump/reload? Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: UI improvements
Alexander Limi wrote: On Thu, 24 Nov 2005 02:06:11 -0800, Chris Withers [EMAIL PROTECTED] wrote: Indeed, but my comment wasn't so much about this particular change, it was about the principle of it. If 2.9 is already feature-frozen, then we're setting a dangerous precedent for allowing feature changes on it. well, if he did it, why can't I? My changes are just as small etc... Well, there was a statement saying that 2.9 isn't frozen yet, IIRC? Indeed, sorry, I jumped the gun on that one, but double check with Andreas in case it now _has_ been frozen... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: UI improvements
Tino Wildenhain wrote: Not sure which objects would fall in this category. All Objects in ZODB have their history - they just dont show it by default. Comparison is of course specific to a class. Indeed, how will this work? Historycopy is of course another thing. It works for all objects but especially folders are a bit sensible if some subobjects got renamed - thats why I dont support history copy on folders. OK. So, how's this coming? ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: UI improvements
Chris Withers schrieb: Tino Wildenhain wrote: Not sure which objects would fall in this category. All Objects in ZODB have their history - they just dont show it by default. Comparison is of course specific to a class. Indeed, how will this work? Historycopy is of course another thing. It works for all objects but especially folders are a bit sensible if some subobjects got renamed - thats why I dont support history copy on folders. OK. So, how's this coming? ;-) You can check the principle with my old monkey-patch proof of concept. Due to changes of the extensionclasses, it only works with 2.7. I've got working code for 2.8 here, but I dont want to maintain it as monkey patch anymore. http://www.zope.org/Members/tino/PatchHistory/view Regards Tino ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Python2.4 Security Audit ETA???
The security audit already happened, and led to checkins by Jim on October 26 that preceded the release of Zope 2.8.4. Zope 2.8.4 is safe to use with python 2.4. Florent Alan Milligan wrote: Aeons ago someone promised that said Zope security audit of Python 2.4 was scheduled for October. I've not yet seen any happy announcements that Zope is now 2.4 compliant, and do want to highlight the importance of achieving this goal. Python2.4 has been out for almost a year now, and it's fairly ubiquitous. There've been many statements made on this list about people quite happily running their Zope's - contrary to white hat advice. With the major distro's, Python is entrenched in their installer and gui processes and *all* packaging is focused around a single python (2.4 for everyone excepting our BastionLinux). In reality it is infeasible to support a second version of Python for Z2. Many modules have SWIG bindings (while core Z2 doesn't require much of this, a number of products do), requiring multiple package versions - build systems cannot cope with this scenario without massive spec customisations (which is all pointless given the window of this requirement - and of course that we've all actually learnt something for python2.5, python2.6 ) We are getting an increasing number of people attempting to load incompatible packages. It is not possible to downgrade python. Most of userland is not competent to get a secondary python2.3 installation running - especially when packages such as python-ldap are simply not available for their old python and new ldap etc etc which all requires custom package builds. We are also stuck in a time-warp actually having to back-port a large proportion of recent linux packages because we'd like to make new features available, increasing costs and testing requirements. It is also no longer possible for customers to subscribe to just a single channel because our core is substantially different to their chosen vendor's installation, and packages will be installed into meaningless python paths etc. Can someone please give me an ETA on this, so I can decide if and how to support zope in light of other pressing linux requirements for our distro. -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: PermissionGeddon
Hi all, Em Dom, 2005-11-27 às 21:26 +0100, Florent Guillaume escreveu: Dieter Maurer wrote: The first change is in the manage_pasteObjects method of CopyContainer. There are some _setObject and _delObject calls which grew a new suppress_events parameter. [...] Several Folder like classes are likely to overwrite _setObject and _delObject. Maybe, the code that calls these methods with an additional parameter should be prepared to meet implementations that do not support the extra parameter. Maybe. But on the other hand I'd rather not have object manager code slowed down and uglified to suit the negligibly small number of classes that are in this case, and that can be trivialy upgraded in a forward-compatible manner. Not gathering crust is a nice an laudable goal, but so is keep backward compatibility. I humbly suggest that the workaround code on ObjectManager be created with a deprecation warning whenever it's triggered, declaring that the backward compatibility will go away in, say, version 2.11, when it won't be uglified and slowed down anymore. You are, in essence, changing the API. IMHO this should take the same deprecation treatment as everything else. Cheers, Leo. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: PermissionGeddon
Dieter Maurer wrote: Hanno Schlichting wrote at 2005-11-26 09:28 +0100: ... I hope to have tracked the ~200 failing tests down to two of your changes in OFS.CopySupport. The first change is in the manage_pasteObjects method of CopyContainer. There are some _setObject and _delObject calls which grew a new suppress_events parameter. This breaks the reference implementation of Archetypes because it uses something based on BTreeFolder2 to store references and BTreeFolder2 overwrites both _setObject and _delObject with its own versions. Several Folder like classes are likely to overwrite _setObject and _delObject. Maybe, the code that calls these methods with an additional parameter should be prepared to meet implementations that do not support the extra parameter. Ok, due to popular demand I'll make such a change. I'm a bit peeved though at the lack of willingness from the few people that have reimplemented their version of _setObject/_delObject (which could be considered private APIs, seeing that they're prefixed with an underscore) to just modify their code for forward compatibility and be done with it, but instead have us embark in a year-long deprecation strategy. This is supposed to be open source, can't we be reactive to change in such situation? Are folks really going to ship their framework code with _setObject unmodified from the current version when they ship it for Five 1.2 or Zope 2.9? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1849 Blamelist: benji_york,efge,philikon,rafrombrc,tseaver,yuppie BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: PermissionGeddon
On 26 Nov 2005, at 09:28, Hanno Schlichting wrote:
The second change is actually related to your permission work.
First of all I have to thank you for your great work :) But I have
found one nasty thing.
CopySupport had the following security declaration:
__ac_permissions__=(('Copy or Move', (), ('Anonymous', 'Manager',)),)
...
Globals.default__class_init__(CopySource)
which changed into:
security = ClassSecurityInfo()
security.setPermissionDefault(copy_or_move, ('Anonymous', 'Manager'))
...
InitializeClass(CopySource)
Now the InitializeClass call is actually an alias for the former
Globals call, so no change here. But as you wrote yourself, you had
some trouble with the mysterious __ac_permissions format.
Looking at the actual code in App.class_init in the last paragraph
I'm quite sure that the former code did effectivly nothing so far.
The actual setattr call is inside a 'for mname in mnames:' loop
where mnames is the second element of each security tuple - in this
special case the mysterious () which results in not going through
the 'for mname in mnames:' loop at all.
Ok I just fixed SecurityInfo, could you update AccessControl/ and
recheck please?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 1851 Blamelist: efge BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: PermissionGeddon
Hi Florent Em Ter, 2005-11-29 às 15:32 +0100, Florent Guillaume escreveu: [...] I'm a bit peeved though at the lack of willingness from the few people that have reimplemented their version of _setObject/_delObject (which could be considered private APIs, seeing that they're prefixed with an underscore) to just modify their code for forward compatibility and be done with it, but instead have us embark in a year-long deprecation strategy. This is supposed to be open source, can't we be reactive to change in such situation? Are folks really going to ship their framework code with _setObject unmodified from the current version when they ship it for Five 1.2 or Zope 2.9? They probably will change it, people don't like their code to generate deprecation warnings. But the greatest beneficiaries of the deprecation strategy are not the framework builders, but the users. Suppose a Zope change breaks, say, Plone (to pick two arbitrary examples :-). This means, that in order to upgrade to the next Zope version, I need to upgrade Plone first. If Plone, on the other hand, depends on Zope features that are only available in the newer Zope version, I'm forced to upgrade both layers of my running site simultaneously, making it much more expensive to calculate the migration overhead and procedures. I don't want to start a discussion about whose responsability is to keep compatibility with what software, but I, for one, prefer to upgrade the lower layers of my solutions before the upper layers if possible: Python before Zope, Zope before Plone, Linux kernel before glibc. This is not always possible, and there are loads of counter-examples, but if we can avoid forcing the poor user to upgrade more than one piece of software at a time, I think this is something we should try to achieve. Cheers, Leo ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: DateTime mess
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: Frankly, anything which attempts to fix pickles in-place smells bad to me. Dump and reload is how the RDBMS world handles this kind of problem, and it isn't because they don't have smart folks working on them. You're right, as nice as generations might be, they can't work around some of the architectural flaws of the ZODB. I wouldn't call them flaws; schema changes are *hard* in RDBMS land, too. And, of course, they've not been battle tested, but who's going to battle test them until they are battle tested? Chicken... egg... :). So, do I take it that you're suggesting the upgrade strategy should entail some sort of dump/reload? Yes, and for a perfect example of why (not related to DateTime, just to fix-in-place in general) prosecution calls zope.org. Pros: Is it true that you harbor pickles from software which pre-dates the original public release of the PTK, almost six years ago? Witness (sobbing): Yes! Yes! it is true. They could have cleaned me out by doing a data migration into a fresh ZODB, but they thought they were clever enough to update me in place. I feel so *used*! Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDjHgT+gerLs4ltQ4RAhV5AJ9RkELpcCehxidfHX3to+i35WKt5ACcDOyk +oqPpq0HwiU0whiwvVOIdlc= =8Ixv -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Python2.4 Security Audit ETA???
--On 29. November 2005 15:13:45 +0100 Florent Guillaume [EMAIL PROTECTED] wrote: The security audit already happened, and led to checkins by Jim on October 26 that preceded the release of Zope 2.8.4. Zope 2.8.4 is safe to use with python 2.4. Let's say it this way: it's safer than with Zope 2.8.3 but it is still not supported :-) -aj pgpLBMkb7XQdX.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: PermissionGeddon
Dieter Maurer wrote: Hanno Schlichting wrote at 2005-11-26 09:28 +0100: ... I hope to have tracked the ~200 failing tests down to two of your changes in OFS.CopySupport. The first change is in the manage_pasteObjects method of CopyContainer. There are some _setObject and _delObject calls which grew a new suppress_events parameter. This breaks the reference implementation of Archetypes because it uses something based on BTreeFolder2 to store references and BTreeFolder2 overwrites both _setObject and _delObject with its own versions. Several Folder like classes are likely to overwrite _setObject and _delObject. Maybe, the code that calls these methods with an additional parameter should be prepared to meet implementations that do not support the extra parameter. I checked in a backward compatibility check for this too. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: DateTime mess
On 29 Nov 2005, at 15:47, Tres Seaver wrote: Yes, and for a perfect example of why (not related to DateTime, just to fix-in-place in general) prosecution calls zope.org. Pros: Is it true that you harbor pickles from software which pre-dates the original public release of the PTK, almost six years ago? Witness (sobbing): Yes! Yes! it is true. They could have cleaned me out by doing a data migration into a fresh ZODB, but they thought they were clever enough to update me in place. I feel so *used*! sound of studio audience cheering wildly Moderator turns around. Camera turns to him and zooms in on his somber-looking face. Moderator: Amen. Screen goes black ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: DateTime mess
A question that then pops up is: Do we want to force people to do a migration to upgrade between say Zope 2.9 and Zope 2.10, just to replace all the DateTime pickles? Especially since we still need to provide API-compatibility? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: DateTime mess
--On 29. November 2005 17:36:51 +0100 Lennart Regebro [EMAIL PROTECTED] wrote: A question that then pops up is: Do we want to force people to do a migration to upgrade between say Zope 2.9 and Zope 2.10, just to replace all the DateTime pickles? Especially since we still need to provide API-compatibility? For people it might be more comfortable to have a on-the-fly migration somehow under the hood...however this leads to ugly migration code in the sources (Zope is full of such scary code). Personally I prefer a dedicated migration step. -aj pgppUUYRDzhKC.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Folderish or SimpleItem object types for structural content
Martijn Jacobs wrote at 2005-11-29 01:02 +0100: All those products are different 'types', with different functionality and different 'roles' as what they represent, so I write different products for every type. For every object that can contain subobjects you could derive it from 'Folder' (or Object Manager). But when you derive all these product types from 'Folder' you end up with ALOT of objects in your database. It that a problem? It might become one once you get millions of objects... Usually, I would expect that most objects come from you leaves and not from the classification structure... In a lot of real world cases you have categories and items, that makes things easy, but what about the structure explained above? I would use ObjectManagers to implement the classification structure and SimpleItems for the leaves. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Folderish or SimpleItem object types for structural content
Hello Dieter. ...For every object that can contain subobjects you could derive it from 'Folder' (or Object Manager). But when you derive all these product types from 'Folder' you end up with ALOT of objects in your database. It that a problem? It might become one once you get millions of objects... Usually, I would expect that most objects come from you leaves and not from the classification structure... That will be true, but I was wondering where to draw the line, for example with perfomance issues. All the objects will be in a ZCatalog, to allow searching for example. But one 'ObjectManager' step less in the choice what to do with the products results in much less objects in the catalog. The estimation about the amount of objects, with only the leave nodes as 'SimpleItem' objects will be 30.000. I never had so many objects in a ZODB, that's why I'm asking this, but as your answer suggests it's still the preferred way. Thanks for the comments! -- Martijn Jacobs Four Digits, internet solutions e-mail: [EMAIL PROTECTED] | web: http://www.fourdigits.nl tel: +31 (0)26 44 22 700 | fax: +31 (0)84 22 06 117 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: PermissionGeddon
Florent Guillaume wrote: Ok I just fixed SecurityInfo, could you update AccessControl/ and recheck please? Florent Hi Florent. All our unit tests pass again. I'm really looking forward for having a new Zope .0 release which might be compatible with an existing Plone release ;) Great work, thanks so much! Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: DateTime mess
On 29 Nov 2005, at 16:46, Andreas Jung wrote: --On 29. November 2005 17:36:51 +0100 Lennart Regebro [EMAIL PROTECTED] wrote: A question that then pops up is: Do we want to force people to do a migration to upgrade between say Zope 2.9 and Zope 2.10, just to replace all the DateTime pickles? Especially since we still need to provide API-compatibility? For people it might be more comfortable to have a on-the-fly migration somehow under the hood...however this leads to ugly migration code in the sources (Zope is full of such scary code). Personally I prefer a dedicated migration step. +1 on a dedicated migration step. Might even be a chance for some other cleanups. jens ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: RFC: product initialization cleanup and improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Ouch! I thought everything is in place for that feature, but an important piece of the puzzle is missing: The fix for checkPermission. http://www.zope.org/Collectors/Zope/1774 _verifyObjectPaste uses a hack to work around that checkPermission issue, making 'action' required. Tres: You did have a look at issue #1774 a while ago. What do you think: How much work would it be to resolve this issue? I'm not a C programmer so I can't do it myself... I have uploaded a patch, with tests, to the collector issue: http://www.zope.org/Collectors/Zope/1774/collector_1774.patch/view I could use another pair of eyeballs on the C part of the code -- the refcount idioms in that code are pretty nasty, and I finally rewrote them using 'goto' and Py_XDECREF. The patch (against the 2.8 branch) applies cleanly to the 2.9 branch and the trunk, and all tests pass. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDjR2h+gerLs4ltQ4RAuuNAJ9NW7onXtqWahhbpAGg3zsJl3dC/QCghz9c WfFBTxOeDLDyS/Gp1AN8KxY= =bz/Y -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] Psycopg export/import
William Herring wrote: As part of an object, I have exported several zsql methods from Zope 2.2.2 and imported to Zope 2.6.2. In the later version I am using Psycopg as a database connection to Postgres. It is working fine for all ZSQL methods I have created within 2.6.2. You should consider a version of Zope newer than the ancient 2.6.2... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Zope's Webdav port for RESTful web service
Brad Clements wrote:
PythonScript.py line 368 or so
def PUT(self, REQUEST, RESPONSE):
Handle HTTP PUT requests
self.dav__init(REQUEST, RESPONSE)
self.dav__simpleifhandler(REQUEST, RESPONSE, refresh=1)
self.write(REQUEST.get('BODY', ''))
RESPONSE.setStatus(204)
return RESPONSE
...well, you could always subclass and override ;-)
Plus that method is protected by Change Python Scripts permission as
well.
Why is that a problem?
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] (no subject)
Yes, I feel like that sometimes too ;-) Dennis Allison wrote: -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] DateTime mess
Philipp von Weitershausen wrote: I think we need Zope to use some frankendatetime (a datetime.datetime that also supports the old DateTime API) throughout the deprecation period. Whenever people make a call to the old DateTime API on a frankendatetime object, they'll get a deprecation warning telling them to use the datetime.datetime API instead. After the deprecation phase is over, Zope 2 can return pure datetime.datetime objects. I don't see any need for diabolical creations ;-) Just the deprecation warnings will suffice. (...which will promptly be added to warn filters, and only fixed when DateTime really goes away *sigh*) By the way, this is really not a thread for zope@zope.org but for [EMAIL PROTECTED] From the beginning, actually. I suggest we move all further discussion there. Yup, but how do we make sure the good folks at zope3-dev get involved and know what we're up to? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] DateTime mess
Andrew Milton wrote: -1 for any scheme that deliberately breaks currently working code / installs. It's pretty broken already ;) -1 for any scheme that involves diddling the ZODB to 'fix' pickles, because you just know you're going to corrupt someone's ZODB, and that's just noone's idea of fun. Yup, I'd agree with this... Didn't see any mention of fixing ZClasses (not sure if that's an issue). Hahaha. You'rea funny man ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] DateTime mess
Philipp von Weitershausen wrote: Chris suggests. Why does it need to be persistent? See the use case I sketched out in my other reply... 1. Create some extensive tests about how DateTime currently works. I'm currently working on this to see whether any further procedure makes sense. yay! 2. If we find it's possible, we rid the current DateTime implementation and recreate the DateTime class by subclassing datetime.datetime. For backwards compatability, we make sure that old pickles can be revived and that the old DateTime API is supported for two more Zope releases. -1 Too complicated. I prefer the deprecate, provide migration utility, then remove method... 3. After two releases we get rid of the old DateTime API and will provide a script to migrate old DateTime pickles to datetime.datetime pickles in the ZODB. ...yes, this. Just skip step 2 ;-) By the way, I only skimmed over this thread, but I haven't actually found anywhere explained what Hermann's problem with strftime was and a detailed suggestion on how his rewrite would take place... Maybe it'd be a good idea to adopt the proposal process we have for Zope 3. As I said elsewhere, I'd love to have one datetime and timezone story for both Zope 2 and Zope 3, and I think Zope 3 has better processes for making that happen ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope 2.8.4 strange behavior
Chris McDonough wrote: The symptom you're describing has happened to me in the past. Zope stops serving requests and my CPU is not pegged (it's not hitting the CPU hard via an infinept loop I've made). I usually end up tracking it down to the fact that my instance is somehow leaking database connections. I thought Jim solved this for 2.8 by not having a hard limit on the connection pool? (iirc, you now get errors in the log when you go over the pool limit) This was 'cos you used to get the crappy situation running unit tests when lots of test fail that things hang and you get no feedback apart from 7 E's because the connection pool is exhausted. That said, I don't know for sure that Jim _did_ end up implementing this, I might just be imagine it. Jim? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] why will FastCGI not be supported in the Future.
Gerhard Schmidt wrote: I pretty sure that mod_proxy is much better than pcgi was. But logic tells me that it can't be better than fastcgi. Well, you logic is apparently different from everyone elses ;-) I'm with the everyone-else here, so quite whining about FCGI unless you want to maintain it... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] DateTime mess
Lennart Regebro wrote: Just a note: I don't think mixing in persistance is needed. Hmm... how so? I've always thought it quite nice that when, for example, you store the modification time of an object in a DateTime, you can safely update it without worrying about the whole object having to be repickled when you change it... CalZope uses datetime objects straight off the rocks, (as attributes to SimpleItems) and they persist just fine. :-) Yes, they will, but that's not the point ;-) There is no default timezone implementation, though. Zope3 has one I think, so it could be used. Yes, I'd verymuch like to see Zope 2 and 3 end up with the same datetime and timezone story, but one that does involve persistence... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] DateTime mess
Chris Withers wrote: Philipp von Weitershausen wrote: I think we need Zope to use some frankendatetime (a datetime.datetime that also supports the old DateTime API) throughout the deprecation period. Whenever people make a call to the old DateTime API on a frankendatetime object, they'll get a deprecation warning telling them to use the datetime.datetime API instead. After the deprecation phase is over, Zope 2 can return pure datetime.datetime objects. I don't see any need for diabolical creations ;-) Just the deprecation warnings will suffice. (...which will promptly be added to warn filters, and only fixed when DateTime really goes away *sigh*) Ok, so take this example: A piece of code calls bobobase_modification_time() which currently returns a DateTime; after that the piece of code calls some DateTime-specific methods on the returned object. Now in Zope 2.12 we make bobobase_modification_time() return a datetime.datetime and subsequently the piece of code would fail. There are a lot of pieces of code like this in third party products... We could deprecate DateTime now to warn people about that. But then their product would only either work with Zope 2.12 or with Zope 2.12 (depending on whether it still expects the DateTime API or the datetime.datetime API); it would not with both versions. That's a harsh upgrade plan and it would probably take ages before people would adopt Zope 2.12. With a frankendatetime in Zope 2.10, however, they could still call DateTime-specific methods on the return value of bobobase_modification_time(). They'd get deprecation warnings telling them to use the datetime.datetime API instead. That would work instantly, not only in Zope 2.12. That way they could smoothly upgrade their products. By the way, I've come to think that touching the current DateTime implementation wouldn't be a good idea, mostly because of the old pickles issue. The frankendatetime should be a separate class that subclasses datetime.datetime, provides old-style DateTime compatability and has datetime.datetime-compatible pickles. Philipp ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Question about Stepper
Pardon my stupidity but is Chris Withers' Stepper the right thing for me...? I've got a message central that accepts and sends messages. The system has an in-part and and out-part that is quite separate. Then there's third party code that looks a bit like this: pseudocode def acceptIncomingMessage(self, message): # add to the queue self.getMCentral().storeMessage(message) # process all (should be only one) items off the queue self.getMCentral().sendAllUnsent() return cool /pseudocode The call to sendAllUnsent() I would prefer if it was done asyncronously in case it takes several seconds. I could accomplish this by having a cron job calling it every 5 minutes but ldeally I don't want to rely on cron for this setup. Is Stepper the right thing for me? -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Question about Stepper
On 29 Nov 2005, at 11:12, Peter Bengtsson wrote: Pardon my stupidity but is Chris Withers' Stepper the right thing for me...? yes The call to sendAllUnsent() I would prefer if it was done asyncronously in case it takes several seconds. I could accomplish this by having a cron job calling it every 5 minutes but ldeally I don't want to rely on cron for this setup. Is Stepper the right thing for me? Stepper still needs cron. It is not a cron replacement. jens ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] DateTime mess
On 11/29/05, Chris Withers [EMAIL PROTECTED] wrote: Hmm... how so? I've always thought it quite nice that when, for example, you store the modification time of an object in a DateTime, you can safely update it without worrying about the whole object having to be repickled when you change it... Oh, so that make a difference? datetime objects are unchangeable, so everytime you change it you will have to set the attribute, and I thought the whole object got pickled then, but I guess that it doesn't, then. I that case, a persistance-aware datetime could be beneficial. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] DateTime mess
On 11/29/05, Philipp von Weitershausen [EMAIL PROTECTED] wrote: We could deprecate DateTime now to warn people about that. But then their product would only either work with Zope 2.12 or with Zope 2.12 (depending on whether it still expects the DateTime API or the datetime.datetime API); it would not with both versions. That's a harsh upgrade plan and it would probably take ages before people would adopt Zope 2.12. I agree, official deprecation and warnings should only happen when we have a real backwards compatibility and transition-path. Which would include what you call a frankendatetime. :-) Which, as I understand it, is what Jürgen Herrman wanted to create... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] DateTime mess
[ Lennart Regebro wrote:] On 11/29/05, Philipp von Weitershausen [EMAIL PROTECTED] wrote: We could deprecate DateTime now to warn people about that. But then their product would only either work with Zope 2.12 or with Zope 2.12 (depending on whether it still expects the DateTime API or the datetime.datetime API); it would not with both versions. That's a harsh upgrade plan and it would probably take ages before people would adopt Zope 2.12. I agree, official deprecation and warnings should only happen when we have a real backwards compatibility and transition-path. Which would include what you call a frankendatetime. :-) Which, as I understand it, is what Jürgen Herrman wanted to create... correct that is ;) regards, juergen herrmann ___ XLhost.de - eXperts in Linux hosting Jürgen Herrmann Bruderwöhrdstraße 15b, DE-93051 Regensburg Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 WEB: http://www.XLhost.de ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] DateTime mess
Lennart Regebro wrote: I agree, official deprecation and warnings should only happen when we have a real backwards compatibility and transition-path. Which would include what you call a frankendatetime. :-) Which, as I understand it, is what Jürgen Herrman wanted to create... Not if I understand http://article.gmane.org/gmane.comp.web.zope.general/49975 correctly. There he says something about using datetime as a storage, but not as the end point of a deprecation period. Philipp ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: DateTime mess
Chris Withers wrote: Just a note: I don't think mixing in persistance is needed. Hmm... how so? I've always thought it quite nice that when, for example, you store the modification time of an object in a DateTime, you can safely update it without worrying about the whole object having to be repickled when you change it... Except that this doesn't work that way today. DateTime object don't subclass persistent. What you're proposing doesn't make much sense to me anyway, if you want to change the modification time of an object then it means something else changed. No need to isolate the modification time change in its own persistent subobject. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope 2.8.4 strange behavior
[Chris McDonough] The symptom you're describing has happened to me in the past. Zope stops serving requests and my CPU is not pegged (it's not hitting the CPU hard via an infinept loop I've made). I usually end up tracking it down to the fact that my instance is somehow leaking database connections. [Chris Withers] I thought Jim solved this for 2.8 by not having a hard limit on the connection pool? This was implemented for ZODB 3.4. See: http://www.zope.org/Wikis/ZODB/SimplifyConnectionManagement and ZODB NEWS. (iirc, you now get errors in the log when you go over the pool limit) Messages at warning or critical level, depening on how much you've gone over. This was 'cos you used to get the crappy situation running unit tests when lots of test fail that things hang and you get no feedback apart from 7 E's because the connection pool is exhausted. Not really (see the Wiki page referenced above). That said, I don't know for sure that Jim _did_ end up implementing this, I might just be imagine it. It was released in ZODB 3.4a1: What's new in ZODB3 3.4a1? == Release date: 01-Apr-2005 ... DB -- - There is no longer a hard limit on the number of connections that ``DB.open()`` will create. In other words, ``DB.open()`` never blocks anymore waiting for an earlier connection to close, and ``DB.open()`` always returns a connection now (while it wasn't documented, it was possible for ``DB.open()`` to return ``None`` before). ``pool_size`` continues to default to 7, but its meaning has changed: if more than ``pool_size`` connections are obtained from ``DB.open()`` and not closed, a warning is logged; if more than twice ``pool_size``, a critical problem is logged. ``pool_size`` should be set to the maximum number of connections from the ``DB`` instance you expect to have open simultaneously. In addition, if a connection obtained from ``DB.open()`` becomes unreachable without having been explicitly closed, when Python's garbage collection reclaims that connection it no longer counts against the ``pool_size`` thresholds for logging messages. The following optional arguments to ``DB.open()`` are deprecated: ``transaction``, ``waitflag``, ``force`` and ``temporary``. If one is specified, its value is ignored, and ``DeprecationWarning`` is raised. In ZODB 3.6, these optional arguments will be removed. And for ZODB 3.6, they were removed. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Zope's Webdav port for RESTful web service
On 29 Nov 2005 at 9:53, Chris Withers wrote: Brad Clements wrote: PythonScript.py line 368 or so def PUT(self, REQUEST, RESPONSE): ...well, you could always subclass and override ;-) Plus that method is protected by Change Python Scripts permission as well. Why is that a problem? My point was that I wanted to create a REST compliant interface in PythonScript, without having to create any Zope products. That is not possible given the current design. Just a simple statement, that is all. -- Brad Clements,[EMAIL PROTECTED](315)268-1000 http://www.murkworks.com AOL-IM or SKYPE: BKClements ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Error Executing runzope Command
Hello. I just installed Zope 2.7.0 on Mac OS X Tiger and I running it with MacPython 2.3.3. I installed Zope in /usr/local. Now, when I try to execute './runzope' or './zopectl start', I receive the following error: Fatal Python error: PyThreadState_Get: no current thread Has anyone experienced this before? If so, could you please tell me why this error is being thrown? Thank you. - Asad ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Error Executing runzope Command
Thanks for your input. So, I went ahead and installed Zope 2.8.4 and the configuration script used Python 2.3.5 which comes installed with Mac OS X Tiger. Now, when I try to execute ./runzope, I get the following error: File /usr/local/lib/python/persistent/interfaces.py, line 19, in ? from zope.interface import Interface ImportError: No module named zope.interface Why is this module missing? - Asad On Tue, 29 Nov 2005, Andreas Jung wrote: --On 29. November 2005 10:43:23 -0500 Asad Habib [EMAIL PROTECTED] wrote: Hello. I just installed Zope 2.7.0 on Mac OS X Tiger and I running it with MacPython 2.3.3. I installed Zope in /usr/local. Now, when I try to execute './runzope' or './zopectl start', I receive the following error: Zope 2.7.0? This version is *very* ancient. Try a recent version (2.8.4) and possibly use a Python version compiled from the Python sources directly. -aj ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Error Executing runzope Command
--On 29. November 2005 11:35:07 -0500 Asad Habib [EMAIL PROTECTED] wrote: Thanks for your input. So, I went ahead and installed Zope 2.8.4 and the configuration script used Python 2.3.5 which comes installed with Mac OS X Tiger. Now, when I try to execute ./runzope, I get the following error: File /usr/local/lib/python/persistent/interfaces.py, line 19, in ? from zope.interface import Interface ImportError: No module named zope.interface Why is this module missing? Works fine for me. Did you install Zope *properly* from the sources? -aj pgp21p3DCSDao.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Stepper 1.4.0 Released!
Stepper is a framework for scripting and running asynchronous tasks on Zope servers. This is a new release fixing several bugs and introducing some minor new features. The major changes for this release were: - A bug was fixed which prevented run.py from being used. - Chains can now be nested within chains. - Transaction control is tighter, making sure objects aren't left in an inconsistent state. - Error handling and progress feedback have been improved. For more information, please see: http://www.simplistix.co.uk/software/zope/stepper cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope 2.8.4 strange behavior
Paul Winkler wrote at 2005-11-28 15:37 -0500:
...
We had to implement a keep alive mechanism to prevent our firewall
from behaving in this nasty way.
OK. Can you give a high-level summary of what you did? I thought of
using heartbeat to detect loss of connection, but I'm not sure what I
could do on failure short of restarting Zope.
We knew that our firewall shuts down connections with a timeout
of 30 min. Thus, we have send our ZEO a keep alive message
every 20 min. The code roughly looks like this:
KeepPeriod= int(environ.get('ZEO_KEEP_ALIVE')) * 60
Storage = getConfiguration().dbtab.getDatabase('/')._storage
def keepAlive():
LOG(CustomZODB,INFO,Keep alive thread started)
while 1:
sleep(KeepPeriod)
if Storage._ready.isSet():
LOG(CustomZODB,INFO,Sending keep alive message)
Storage._load_lock.acquire()
try:
try:
Storage._server.get_info()
LOG(CustomZODB,INFO,Sent keep alive message)
except:
LOG(CustomZODB,ERROR, failed, error=exc_info())
finally: Storage._load_lock.release()
else:
LOG(CustomZODB,PROBLEM,Connection is down)
start_new_thread(keepAlive,())
--
Dieter
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Error Executing runzope Command
Asad Habib wrote at 2005-11-29 11:35 -0500: Thanks for your input. So, I went ahead and installed Zope 2.8.4 and the configuration script used Python 2.3.5 which comes installed with Mac OS X Tiger. Now, when I try to execute ./runzope, I get the following error: File /usr/local/lib/python/persistent/interfaces.py, line 19, in ? from zope.interface import Interface ImportError: No module named zope.interface Why is this module missing? Looks like something went wrong with your Zope 2.8.4 installation. zope.interface is the Zope 3 (part of Zope since Zope 2.8.x) interface module. It is there in a correct installation. Did you configure; make; make [install|inplace] correctly? Do you start Zope in a correct instance (create with mkzopeinstance)? -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope 2.8.4 strange behavior
Resolved. Thanks to all that responded. The symptoms were due to an external method which runs a program (htmldoc) that converts html to pdf. The external method uses the old subprocess interface to fire off the process and then wait() for it to complete. To fix another problem, we had upgraded to the latest version, but that htmldoc version apparently is confused by some of our html input and never completes so the external method just sits there waiting for the child process to terminate. Multiple invokations of the blocked htmldoc process eventually brought Zope to its knees and no further progress was made. Confession is good for the soul The problem took a long time to find because failures were infrequent (we only saw three or for instances) so there was limited data. Moreover,the external method the was failing had been in service for almost two years and has not been a problem. And, other very similar external methods which also use htmldoc were known to work with the upgraded htmldoc. It was not until the external method was identified as the only commonality in the failures that I thought to look closely at the external method. And then I noticed the blocked htmldoc processes, etc. etc. The fix Our solution was to revert htmldoc to the earlier version. When time permits we'll add a timeout to the external method and try to extablish what in the current release htmldoc triggered the failure. We probably should move to the new subprocess module rather than use popen2 in the external method. On Sun, 27 Nov 2005, Dennis Allison wrote: Python2.4.2 Zope 2.8.4 ZODB/Zeo 2.3.4 Mysql 4.0 Dual Athalon processors Linux RH7.3 We have two recent instances in our production sites where Zope suddenly stops responding. It is not a new problem, but we've now been confronted with two clean examples and nothing to blame them on. The problem appears to be independent of load as both incidents were on lightly loaded machines. A check of the logs (Linux and Zope) shows nothing obviously amiss except that the trace log (the old -M log) shows a sudden increase in active requests from the typical 0 or 1 to 1300 or more. In this context an active request' is total number of requests pending at the end of this request and is computed by post-processing. We front-end Zope with pound and make heavy use of MySQL. Both show a plethora of incomplete transactions. Examination of the raw trace log shows that Zope is continuing to accept requests, but nothing getting done. The raw log date-stamps four internal states for each transaction. The states are Begin (B), Input (I), action (A), and End (E). Inputs are gathered between B and I, outputs is made between A and E. The raw log shows B and I transactions, but apparently no processing is completing. I suspect that nothing is getting scheduled. I am at a loss as to where to begin to track this one down. The failure is spontaneous and apparently not triggered by any readily distinguishable inputs or pattern of inputs. The behavior smells a bit of resource limits or process synchronization problems, but there is not real evidence for either being the root cause. I am not sure what monitoring I should be doing to help locate the source of the problem. Has anyone seen seen a similar problem? Any advice as to how to proceed? -- ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Zope 2.8.4 strange behavior
Dieter Maurer wrote:
Paul Winkler wrote at 2005-11-28 15:37 -0500:
...
We had to implement a keep alive mechanism to prevent our firewall
from behaving in this nasty way.
OK. Can you give a high-level summary of what you did? I thought of
using heartbeat to detect loss of connection, but I'm not sure what I
could do on failure short of restarting Zope.
We knew that our firewall shuts down connections with a timeout
of 30 min. Thus, we have send our ZEO a keep alive message
every 20 min. The code roughly looks like this:
KeepPeriod= int(environ.get('ZEO_KEEP_ALIVE')) * 60
Storage = getConfiguration().dbtab.getDatabase('/')._storage
def keepAlive():
LOG(CustomZODB,INFO,Keep alive thread started)
while 1:
sleep(KeepPeriod)
if Storage._ready.isSet():
LOG(CustomZODB,INFO,Sending keep alive message)
Storage._load_lock.acquire()
try:
try:
Storage._server.get_info()
LOG(CustomZODB,INFO,Sent keep alive message)
except:
LOG(CustomZODB,ERROR, failed, error=exc_info())
finally: Storage._load_lock.release()
else:
LOG(CustomZODB,PROBLEM,Connection is down)
start_new_thread(keepAlive,())
Why not use the max-disconnect-poll option of the zeoclient section in
zope.conf ?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] here/content
Can someone tell me how 'here/content' is translated in these lines? span tal:define=stx python:modules['Products'].PythonScripts.standard.structured_text; the_text here/content tal:content=structure python:stx(the_text) The structured text goes here. /span When I use the URL 'www.mysite.org' the above resolves fine, but if I use 'www.mysite.org:8080/mysite' I get a 'Resource not found' when selecting the same link from the homepage of the same site. Is there something I've overlooked? -- John ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope-DB] Z SQL equivelant of MySQL's SQL_CALC_FOUND_ROWS?
On 2005-11-29 at 20:20:10 [+0100], Kevin Monceaux [EMAIL PROTECTED] wrote: Zope Enthusiasts, I'm new to Zope so forgive me if the answer to this question is obvious. If one performs a select with a limit clause is it possible to determine how many results would have been returned if there was no limit? For example, if I wanted to select the first picture in a photo album but wanted to know the total number of pictures in the album, how would I do that via Z SQL? With MySQL it can be done this way: SELECT SQL_CALC_FOUND_ROWS, * from Pictures where AlbumID = 25 LIMIT 1; SELECT FOUND_ROWS() as Count; According to the Z SQL Methods User's Manual multiple SQL statements can be included in a Z SQL method but that no more than one select statement can be included. The above MySQL technique requires two select statements. You can use dtml-var sqldelimiter - search the archives for that. But that is wrong. If you want to count the number of records, use count() Charlie -- Charlie Clark eGenix.com Professional Python Services directly from the Source Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2005-10-17: Released mxODBC.Zope.DA 1.0.9http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
