date:20050929

[Zope-dev] problems setting up methods for a product that registers no classes

2005-09-29 Thread Chris Withers


...zdb in this case.

I need to make a global recompile function available, since zdb 
requires the co_filename attribute of the script's func_code object to 
be set to something meaningful, rather than the useless Script 
(Python) it usually gets set to.


Once zdb is installed, any scripts editted will have this set, but I 
wanted to provide a utility method in a similar vein to python scripts' 
recompile function that could be globally accesed, however since zdb 
registers no classes, I ended up having to do some fairly horrific 
stuff, the following code is from zdb's __init__.py:


# recompilation utlitity
def initialize(context):
# This horrificness is required because Zope doesn't understand the 
concept

# of a Product that doesn't register any classes :-(
pack=context._ProductContext__pack
fd=getattr(pack, '__FactoryDispatcher__', None)
if fd is None:
class __FactoryDispatcher__(FactoryDispatcher):
Factory Dispatcher for a Specific Product

fd = pack.__FactoryDispatcher__ = __FactoryDispatcher__

if not hasattr(pack, '_m'): pack._m=fd.__dict__
pack._m['debug_compile'] = debug_compile
pack._m['debug_compile__roles__'] = ('Manager',)

Now, this breaks in 2.8, so what SHOULD I be doing to make a method 
globally available in a way that works in both 2.7 and 2.8?


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 )

[Zope-dev] Broken objects

2005-09-29 Thread Victor Safronovich

Hello zope-dev!

 http://www.zope.org/Collectors/Zope/1911
 
 I try to migrate my old database from zope 2.6.1.

 I  have Broken objects, but it is impossible to get its state in Zope 2.8.
 In Zope 2.6 Broken objects have states, what i uses to migrate its.
 I think this is because DB.classFactory is overrided to use
 OFS.Uninstalled.BrokenClass, which is bad persistent class.

 the __dict__ of all my Broken objects equals to {'_p_changed':None}.

 my_object._p_mtime does not load it`s state.

-- 
Best regards,
 Victor Safronovich
 NauMen.NauDoc.SoftwareDeveloper  http://www.naumen.ru

___
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] Broken objects

2005-09-29 Thread Chris Withers


Victor Safronovich wrote:

 I  have Broken objects, but it is impossible to get its state in Zope 2.8.
 In Zope 2.6 Broken objects have states, what i uses to migrate its.


I think that was more by luck than by design, but maybe whoever made the 
change can help you out...



 I think this is because DB.classFactory is overrided to use
 OFS.Uninstalled.BrokenClass, which is bad persistent class.


What makes it a bad persisten class?


 the __dict__ of all my Broken objects equals to {'_p_changed':None}.


That seems fair...


 my_object._p_mtime does not load it`s state.


What makes you think it should?

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[2]: [Zope-dev] Broken objects

2005-09-29 Thread Victor Safronovich

Hello Chris Withers,

Thursday, September 29, 2005, 2:44:52 PM, you wrote:

CW I think that was more by luck than by design, but maybe whoever made the
CW change can help you out...
   I think broken object MUST use ZODB.broken.Broken not OFS.Uninstalled.Broken

CW What makes it a bad persisten class?
   it`s not first-class persistent class.

xCW What makes you think it should?
load object state

-- 
Best regards,
 Victor Safronovich
 NauMen.NauDoc.SoftwareDeveloper  http://www.naumen.ru

___
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] Broken objects

2005-09-29 Thread Jim Fulton


Victor Safronovich wrote:

Hello zope-dev!

 http://www.zope.org/Collectors/Zope/1911
 
 I try to migrate my old database from zope 2.6.1.


 I  have Broken objects, but it is impossible to get its state in Zope 2.8.
 In Zope 2.6 Broken objects have states, what i uses to migrate its.
 I think this is because DB.classFactory is overrided to use
 OFS.Uninstalled.BrokenClass, which is bad persistent class.

 the __dict__ of all my Broken objects equals to {'_p_changed':None}.

 my_object._p_mtime does not load it`s state.


Try setting _p_changed=1.

Or try accessing some other attribute.

If that doesn't work, let me know and I'll look into it.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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] 'Savepoints unsupported' on uploading files into zope

2005-09-29 Thread Chris Withers


lavrinenko wrote:

I suspect the bug is in Image.py, and the whole database adapters thing is a
red herring.

Either that, or Shared.ZRDB has become geb0rken in 2.8 when it comes to
savepoints.


..or, as another possibility, both the DA's these errors have been 
reported with haven't been updated to support savepoints, which would 
make the error message more sensible.


Although why the DAs are becoming involved when you're just doing stuff 
with images is beyond me...


RDB-based user folder? ZSQL methods being used somewhere?

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 )

[Zope-dev] Re: 'Savepoints unsupported' on uploading files into zope

2005-09-29 Thread Chris Withers


lavrinenko wrote:

RDB-based user folder? ZSQL methods being used somewhere?


Yes, exUserFolder with MySQL Authentication Source


Try SimpleUserFolder ;-)

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[2]: [Zope-dev] Broken objects

2005-09-29 Thread Victor Safronovich

Hello Jim Fulton,

Thursday, September 29, 2005, 2:57:47 PM, you wrote:

JF Victor Safronovich wrote:
 Hello zope-dev!
 
  http://www.zope.org/Collectors/Zope/1911
  
  I try to migrate my old database from zope 2.6.1.
 
  I  have Broken objects, but it is impossible to get its state in Zope 2.8.
  In Zope 2.6 Broken objects have states, what i uses to migrate its.
  I think this is because DB.classFactory is overrided to use
  OFS.Uninstalled.BrokenClass, which is bad persistent class.
 
  the __dict__ of all my Broken objects equals to {'_p_changed':None}.
 
  my_object._p_mtime does not load it`s state.

JF Try setting _p_changed=1.
  object.__dict__ equals to {'_p_changed':1}

JF Or try accessing some other attribute.
  object.data

  AttributeError('data') raise by OFS.Uninstalled.Broken.__getattr__

Inheritance tree of class BrokenClass:

  + OFS.Uninstalled.BrokenClass
+ __builtin__.ExplicitAcquirer
  + ExtensionClass.Base
- __builtin__.object
+ OFS.SimpleItem.Item
  + ExtensionClass.Base
- __builtin__.object
  + webdav.Resource.Resource
+ ExtensionClass.Base
  - __builtin__.object
+ webdav.Lockable.LockableItem
  - webdav.EtagSupport.EtagSupport
  + OFS.CopySupport.CopySource
+ ExtensionClass.Base
  - __builtin__.object
  + App.Management.Tabs
+ ExtensionClass.Base
  - __builtin__.object
  - OFS.Traversable.Traversable
  + OFS.ZDOM.Element
- OFS.ZDOM.Node
  + AccessControl.Owned.Owned
+ ExtensionClass.Base
  - __builtin__.object
  + App.Undo.UndoSupport
+ ExtensionClass.Base
  - __builtin__.object
+ Persistence.Persistent
  + persistent.Persistent
- __builtin__.object
  + ExtensionClass.Base
- __builtin__.object

Contradictions of inherited attributes in class BrokenClass:

  __delattr__ (wrapper_descriptor)
+ OFS.Uninstalled.BrokenClass
  + __builtin__.ExplicitAcquirer
+ ExtensionClass.Base
  @ __builtin__.object
  + OFS.SimpleItem.Item
+ ExtensionClass.Base
  # __builtin__.object
+ webdav.Resource.Resource
  + ExtensionClass.Base
# __builtin__.object
+ OFS.CopySupport.CopySource
  + ExtensionClass.Base
# __builtin__.object
+ App.Management.Tabs
  + ExtensionClass.Base
# __builtin__.object
+ AccessControl.Owned.Owned
  + ExtensionClass.Base
# __builtin__.object
+ App.Undo.UndoSupport
  + ExtensionClass.Base
# __builtin__.object
  + Persistence.Persistent
# persistent.Persistent
  # __builtin__.object
+ ExtensionClass.Base
  # __builtin__.object

  __getattribute__ (wrapper_descriptor)
+ OFS.Uninstalled.BrokenClass
  + __builtin__.ExplicitAcquirer
@ ExtensionClass.Base
  # __builtin__.object
  + OFS.SimpleItem.Item
# ExtensionClass.Base
  # __builtin__.object
+ webdav.Resource.Resource
  # ExtensionClass.Base
# __builtin__.object
+ OFS.CopySupport.CopySource
  # ExtensionClass.Base
# __builtin__.object
+ App.Management.Tabs
  # ExtensionClass.Base
# __builtin__.object
+ AccessControl.Owned.Owned
  # ExtensionClass.Base
# __builtin__.object
+ App.Undo.UndoSupport
  # ExtensionClass.Base
# __builtin__.object
  # Persistence.Persistent
# persistent.Persistent
  # __builtin__.object
# ExtensionClass.Base
  # __builtin__.object

  __setattr__ (wrapper_descriptor)
+ OFS.Uninstalled.BrokenClass
  + __builtin__.ExplicitAcquirer
+ ExtensionClass.Base
  @ __builtin__.object
  + OFS.SimpleItem.Item
+ ExtensionClass.Base
  # __builtin__.object
+ webdav.Resource.Resource
  + ExtensionClass.Base
# __builtin__.object
+ OFS.CopySupport.CopySource
  + ExtensionClass.Base
# __builtin__.object
+ App.Management.Tabs
  + ExtensionClass.Base
# __builtin__.object
+ AccessControl.Owned.Owned
  + ExtensionClass.Base
# __builtin__.object
+ App.Undo.UndoSupport
  + ExtensionClass.Base
# __builtin__.object
  + Persistence.Persistent
# persistent.Persistent
  # __builtin__.object
+ ExtensionClass.Base
  # __builtin__.object

  __setstate__ (method_descriptor)
+ OFS.Uninstalled.BrokenClass
  + __builtin__.ExplicitAcquirer
@ ExtensionClass.Base
  + OFS.SimpleItem.Item
# ExtensionClass.Base
+ webdav.Resource.Resource
  # ExtensionClass.Base
+ OFS.CopySupport.CopySource
  # ExtensionClass.Base
+ App.Management.Tabs
  #

Re: [Zope-dev] Broken objects

2005-09-29 Thread Jim Fulton


So I guess it didn't work. :)

I'll look into this.  The first step will be to write a test for this.
The intent was definately that you would be able to get to a broken object's
state.

Jim

Victor Safronovich wrote:

Hello Jim Fulton,

Thursday, September 29, 2005, 2:57:47 PM, you wrote:

JF Victor Safronovich wrote:


Hello zope-dev!

http://www.zope.org/Collectors/Zope/1911

I try to migrate my old database from zope 2.6.1.

I  have Broken objects, but it is impossible to get its state in Zope 2.8.
In Zope 2.6 Broken objects have states, what i uses to migrate its.
I think this is because DB.classFactory is overrided to use
OFS.Uninstalled.BrokenClass, which is bad persistent class.

the __dict__ of all my Broken objects equals to {'_p_changed':None}.

my_object._p_mtime does not load it`s state.



JF Try setting _p_changed=1.
  object.__dict__ equals to {'_p_changed':1}

JF Or try accessing some other attribute.
  object.data

  AttributeError('data') raise by OFS.Uninstalled.Broken.__getattr__

Inheritance tree of class BrokenClass:

  + OFS.Uninstalled.BrokenClass
+ __builtin__.ExplicitAcquirer
  + ExtensionClass.Base
- __builtin__.object
+ OFS.SimpleItem.Item
  + ExtensionClass.Base
- __builtin__.object
  + webdav.Resource.Resource
+ ExtensionClass.Base
  - __builtin__.object
+ webdav.Lockable.LockableItem
  - webdav.EtagSupport.EtagSupport
  + OFS.CopySupport.CopySource
+ ExtensionClass.Base
  - __builtin__.object
  + App.Management.Tabs
+ ExtensionClass.Base
  - __builtin__.object
  - OFS.Traversable.Traversable
  + OFS.ZDOM.Element
- OFS.ZDOM.Node
  + AccessControl.Owned.Owned
+ ExtensionClass.Base
  - __builtin__.object
  + App.Undo.UndoSupport
+ ExtensionClass.Base
  - __builtin__.object
+ Persistence.Persistent
  + persistent.Persistent
- __builtin__.object
  + ExtensionClass.Base
- __builtin__.object

Contradictions of inherited attributes in class BrokenClass:

  __delattr__ (wrapper_descriptor)
+ OFS.Uninstalled.BrokenClass
  + __builtin__.ExplicitAcquirer
+ ExtensionClass.Base
  @ __builtin__.object
  + OFS.SimpleItem.Item
+ ExtensionClass.Base
  # __builtin__.object
+ webdav.Resource.Resource
  + ExtensionClass.Base
# __builtin__.object
+ OFS.CopySupport.CopySource
  + ExtensionClass.Base
# __builtin__.object
+ App.Management.Tabs
  + ExtensionClass.Base
# __builtin__.object
+ AccessControl.Owned.Owned
  + ExtensionClass.Base
# __builtin__.object
+ App.Undo.UndoSupport
  + ExtensionClass.Base
# __builtin__.object
  + Persistence.Persistent
# persistent.Persistent
  # __builtin__.object
+ ExtensionClass.Base
  # __builtin__.object

  __getattribute__ (wrapper_descriptor)
+ OFS.Uninstalled.BrokenClass
  + __builtin__.ExplicitAcquirer
@ ExtensionClass.Base
  # __builtin__.object
  + OFS.SimpleItem.Item
# ExtensionClass.Base
  # __builtin__.object
+ webdav.Resource.Resource
  # ExtensionClass.Base
# __builtin__.object
+ OFS.CopySupport.CopySource
  # ExtensionClass.Base
# __builtin__.object
+ App.Management.Tabs
  # ExtensionClass.Base
# __builtin__.object
+ AccessControl.Owned.Owned
  # ExtensionClass.Base
# __builtin__.object
+ App.Undo.UndoSupport
  # ExtensionClass.Base
# __builtin__.object
  # Persistence.Persistent
# persistent.Persistent
  # __builtin__.object
# ExtensionClass.Base
  # __builtin__.object

  __setattr__ (wrapper_descriptor)
+ OFS.Uninstalled.BrokenClass
  + __builtin__.ExplicitAcquirer
+ ExtensionClass.Base
  @ __builtin__.object
  + OFS.SimpleItem.Item
+ ExtensionClass.Base
  # __builtin__.object
+ webdav.Resource.Resource
  + ExtensionClass.Base
# __builtin__.object
+ OFS.CopySupport.CopySource
  + ExtensionClass.Base
# __builtin__.object
+ App.Management.Tabs
  + ExtensionClass.Base
# __builtin__.object
+ AccessControl.Owned.Owned
  + ExtensionClass.Base
# __builtin__.object
+ App.Undo.UndoSupport
  + ExtensionClass.Base
# __builtin__.object
  + Persistence.Persistent
# persistent.Persistent
  # __builtin__.object
+ ExtensionClass.Base
  # __builtin__.object

  __setstate__ (method_descriptor)
+ OFS.Uninstalled.BrokenClass
  + __builtin__.ExplicitAcquirer
@ ExtensionClass.Base
  + OFS.SimpleItem.Item

Re[3]: [Zope-dev] Broken objects

2005-09-29 Thread Victor Safronovich

Hello Victor Safronovich,

Thursday, September 29, 2005, 4:03:17 PM, you wrote:

VS I think __setattr__ and __setstate__ overriden by ExtensionClass, but 
needfully
VS must be from Persistent. Or classFactory must return
VS ZODB.broken.{Persistent}Broken objects
  I changed BrolenClass.__bases__ from Acquisition.Explicit, SimpleItem.Item, 
Persistence.Overridable
  to   Persistence.Overridable,  Acquisition.Explicit, SimpleItem.Item, but this
  is not helped to load state.

  BUT the code below works :))

  shed = app.portal.portal_scheduler # 'shed' is broken object
  con = shed._p_jar
  con._setstate( shed ) # this load state successfully

-- 
Best regards,
 Victor Safronovich
 NauMen.NauDoc.SoftwareDeveloper  http://www.naumen.ru

___
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] Broken objects

2005-09-29 Thread Jim Fulton


Victor Safronovich wrote:

Hello zope-dev!

 http://www.zope.org/Collectors/Zope/1911
 
 I try to migrate my old database from zope 2.6.1.


 I  have Broken objects, but it is impossible to get its state in Zope 2.8.
 In Zope 2.6 Broken objects have states, what i uses to migrate its.
 I think this is because DB.classFactory is overrided to use
 OFS.Uninstalled.BrokenClass, which is bad persistent class.

 the __dict__ of all my Broken objects equals to {'_p_changed':None}.

 my_object._p_mtime does not load it`s state.


Could you tell me more about what you want to happen?

I'm not sure what was happening with state in Zope 2.7, despite the
fact that I wrote that code.  It would be helpful if you could
remind me what the behavior was.

In Zope 2.8, which is to ay ZODB 3.3 and later, the intent is that the
broken objects should provide access to the original state via
the attribute __Broken_state__.  I guess this state isn't being
loaded.  I'll write a test and fix as necessary to make sure it is.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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[2]: [Zope-dev] Broken objects

2005-09-29 Thread Victor Safronovich

Hello Jim Fulton,

Thursday, September 29, 2005, 4:34:31 PM, you wrote:

JF So I guess it didn't work. :)

JF I'll look into this.  The first step will be to write a test for this.
JF The intent was definately that you would be able to get to a broken object's
JF state.

not Test but for example ( if needed i try to spend time to write test )
zopectl debug
Starting debugger (the name app is bound to the top-level Zope object)
 from Persistence import Persistent
 class Test(Persistent):
... def __init__(self, id):
... self.id = id
...
 test1 = Test('test1')
 test2 = Test('test2')
 app.test1 = test1
 app.test1.test2 = test2
 import transaction
 transaction.commit()

# ctrl + d here
zopectl debug
Starting debugger (the name app is bound to the top-level Zope object)
2005-09-29 10:50:09 WARNING ZODB Could not import class 'Test' from module 
'__main__'
 test1 = app.test1
 test1.__dict__
{'_p_changed': None}
 test1._p_activate()
 test1.__dict__
{'_p_changed': None}
 test1.test2
Traceback (most recent call last):
  File stdin, line 1, in ?
AttributeError: test2
 test1.__class__.__bases__
(class 'OFS.Uninstalled.BrokenClass',)
 conn = test1._p_jar
 conn.setstate(test1)
 test1.__dict__
{'test2': __main__.Test object at 0x4015836c, 'id': 'test1'}
 del app.test1
 import transaction
 transaction.commit()





-- 
Best regards,
 Victor Safronovich
 NauMen.NauDoc.SoftwareDeveloper  http://www.naumen.ru

___
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[2]: [Zope-dev] Broken objects

2005-09-29 Thread Victor Safronovich

Hello Jim Fulton,

Thursday, September 29, 2005, 5:02:46 PM, you wrote:

JF Could you tell me more about what you want to happen?
i want to get the states of broken objects, to migrate them.

-- 
Best regards,
 Victor Safronovich
 NauMen.NauDoc.SoftwareDeveloper  http://www.naumen.ru

___
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] Strange security issue with Zope 2.8.1

2005-09-29 Thread Jens Vagelpohl

I have found a strange security issue with Zope 2.8.1 that seems to  
stem from code not doing what it was supposed to do in Zope 2.7.x,  
but which works in 2.8.1 and then causes other side effects in code  
that relied on the broken behavior.


Symptom: In Zope 2.8.1 it is *impossible* to override a  
ClassSecurityInfo security declaration in an Archetypes-derived  
content item. (I have a small set of unit tests that proves the  
behavior under Zope 2.8.1 if anyone is interested)


A little background: When you register an Archetypes-derived content  
type, it will do all the generated accessor/setter method magic and  
then call InitializeClass a second time.


The code in lib/python/App/class_init.py has changed between Zope  
2.7.x and Zope 2.8 in order to support new-style classes. To be more  
precise, instead of manipulating the class __dict__ directly we now  
use setattr/delattr/etc. This change seems to have un-broken code  
which did not do what the code comments suggest. Namely, when a class  
is sent through class_init.default_class_init__ (better known as  
Globals.InitializeClass) the class __dict__ is searched to find  
objects that look like ClassSecurityInfo instances in order to read  
and apply the security settings. After finding the ClassSecurityInfo  
instance, it is force-deleted from the object (the comments say, out  
of paranoia). However, somehow this did not work correctly in Zope  
2.7.x, where the deletion call looked like...


del dict[key]

(dict being the class __dict__, and key being the name of the  
ClassSecurityInfo instance). Under Zope 2.8, it looks like this:


delattr(self, key)

(self being the class object).

Under Zope 2.7, the security object *would still be there* when  
hitting InitializeClass for the second time via Archetypes'  
registerType, which in turn meant Archetypes would not instantiate  
its own ClassSecurityInfo instance and stuff it with the declarations  
from whatever Archetypes-derived base class you used.


In Zope 2.8, the deletion actually works as intended - but due to  
that fact Archetypes will instantiate its own ClassSecurityInfo and  
populate it with the declarations from the base class that I am  
trying to override. So the overridden settings are all overwritten  
again by the base class declaration.


My question is, what is the reasoning behind deleting the  
ClassSecurityInfo object from the class after it has been read the  
first time? How can this be implemented in a sane way so that custom  
security declarations can be retained?


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: Strange security issue with Zope 2.8.1

2005-09-29 Thread Florent Guillaume


Jens Vagelpohl wrote:
I have found a strange security issue with Zope 2.8.1 that seems to  
stem from code not doing what it was supposed to do in Zope 2.7.x,  but 
which works in 2.8.1 and then causes other side effects in code  that 
relied on the broken behavior.


Symptom: In Zope 2.8.1 it is *impossible* to override a  
ClassSecurityInfo security declaration in an Archetypes-derived  content 
item. (I have a small set of unit tests that proves the  behavior under 
Zope 2.8.1 if anyone is interested)


A little background: When you register an Archetypes-derived content  
type, it will do all the generated accessor/setter method magic and  
then call InitializeClass a second time.


The code in lib/python/App/class_init.py has changed between Zope  2.7.x 
and Zope 2.8 in order to support new-style classes. To be more  precise, 
instead of manipulating the class __dict__ directly we now  use 
setattr/delattr/etc. This change seems to have un-broken code  which 
did not do what the code comments suggest. Namely, when a class  is sent 
through class_init.default_class_init__ (better known as  
Globals.InitializeClass) the class __dict__ is searched to find  objects 
that look like ClassSecurityInfo instances in order to read  and apply 
the security settings. After finding the ClassSecurityInfo  instance, it 
is force-deleted from the object (the comments say, out  of paranoia). 
However, somehow this did not work correctly in Zope  2.7.x, where the 
deletion call looked like...


del dict[key]

(dict being the class __dict__, and key being the name of the  
ClassSecurityInfo instance). Under Zope 2.8, it looks like this:


delattr(self, key)

(self being the class object).

Under Zope 2.7, the security object *would still be there* when  hitting 
InitializeClass for the second time via Archetypes'  registerType, which 
in turn meant Archetypes would not instantiate  its own 
ClassSecurityInfo instance and stuff it with the declarations  from 
whatever Archetypes-derived base class you used.


In Zope 2.8, the deletion actually works as intended - but due to  that 
fact Archetypes will instantiate its own ClassSecurityInfo and  populate 
it with the declarations from the base class that I am  trying to 
override. So the overridden settings are all overwritten  again by the 
base class declaration.


My question is, what is the reasoning behind deleting the  
ClassSecurityInfo object from the class after it has been read the  
first time? How can this be implemented in a sane way so that custom  
security declarations can be retained?


My understanding (and the way we use it when monkey patching for instance) 
is that whenevery you apply new security to a class, you create a new 
ClassSecurityInfo on it. It only defines new stuff to do. The real 
synthesized security is still stored in __ac_permissions__.


class C(SimpleItem):
security = ClassSecurityInfo()
security.declareProtected(...)
def foo(): ...

InitializeClass(C)

then later on:

security = ClassSecurityInfo()
C.security = security
security.declareProtected(...)
C.newmethod = something
InitializeClass(C)

Anyway that's what I do. I never relied on a preexisting C.security.

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] problems setting up methods for a product that registers no classes

2005-09-29 Thread Dieter Maurer

Chris Withers wrote at 2005-9-29 09:17 +0100:
...zdb in this case.

I need to make a global recompile function available, since zdb 
requires the co_filename attribute of the script's func_code object to 
be set to something meaningful, rather than the useless Script 
(Python) it usually gets set to.
 ...
Now, this breaks in 2.8, so what SHOULD I be doing to make a method 
globally available in a way that works in both 2.7 and 2.8?

You could use part of the old style initialization, the methods
declaration to be precise.

You see an example in .../Products/ZSQLMethods/__init__.py.

Be warned, however: the old style initialization puts
the declared methods on the OFS.Folder class.

Thus, you better choose a name that is unlikely to conflict
with other methods that might be relevant for classes
derived from Folder...

-- 
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 )

[Zope-dev] problems setting up methods for a product that registers no classes

[Zope-dev] Broken objects

Re: [Zope-dev] Broken objects

Re[2]: [Zope-dev] Broken objects

Re: [Zope-dev] Broken objects

[Zope-dev] 'Savepoints unsupported' on uploading files into zope

[Zope-dev] Re: 'Savepoints unsupported' on uploading files into zope

Re[2]: [Zope-dev] Broken objects

Re: [Zope-dev] Broken objects

Re[3]: [Zope-dev] Broken objects

Re: [Zope-dev] Broken objects

Re[2]: [Zope-dev] Broken objects

Re[2]: [Zope-dev] Broken objects

[Zope-dev] Strange security issue with Zope 2.8.1

[Zope-dev] Re: Strange security issue with Zope 2.8.1

Re: [Zope-dev] problems setting up methods for a product that registers no classes

16 matches

Site Navigation

Mail list logo

Footer information