ZPatterns bug. Very serious.
Hi, look, Phillip, what I found. File Rack.py: def retrieveItem(self,key): # Retrieve an object, identified by key a = self.loadAttrib item = None if a: item = self._RawItem(key) if hasattr(item,a): return item else: # The block below is what you want to replace # if you're creating a non-ZODB storage. # In practice, from version 0.4.0 on, there's # no reason to do such a thing in the first place. slot = self._readableSlot(key) ################################################## # Add this to see what I mean try : print "%s 'self'=%s" % ( key, slot.values()[0].__dict__ ) except : pass # ################################################### if slot: item = slot[SelfKey] # XXX class remapping should go here?? item._setRack(self.aq_inner) item._setSlot(slot) return item ---------------------------------------- The output I have running this modified version (my comments starts with ##): [mike@gw zope]$ ./start ------ 2000-06-22T15:04:07 PROBLEM(100) ZServer Computing default hostname ------ 2000-06-22T15:04:07 INFO(0) ZServer Medusa (V1.13.4.1) started at Thu Jun 22 23:04:07 2000 Hostname: gw.if-site.local Port:8123 ------ 2000-06-22T15:04:07 INFO(0) ZServer PCGI Server started at Thu Jun 22 23:04:07 2000 Unix socket: /home/mike/zope/var/pcgi.soc ## Server just started Nothing to print Nothing to print ## newItem called 000000000025 'self'={'id': '000000000025', '_v_writeableSlot': <PersistentMapping instance at 864ae78>, '_v_readableSlot': <PersistentMapping instance at 864ae78>, '_rackMounted': 1} ## getItem called first time 000000000025 'self'={'_v_attrCache': {'a_': [], 'filtered_manage_optionsisDocTemp': [], '_Change_permissions_Permission': [], 'MANAGE_TABS_NO_BANNER': [], 'im_func': [], '__allow_groups__': [], '_Manage_properties_Permission': [], 'tabs_path_infoisDocTemp': [], '__roles__': [], 'target': [], '_View_Permission': [], 'Zope-Version': [], 'locked_in_versionisDocTemp': [], 'n_': [], 'PATH_INFO': [], 'AUTHENTICATED_USER': [], 'manage_tabs_message': [], 'tabs_path_info__roles__': [], 'SCRIPT_NAME': [], 'REQUEST': [], '__bobo_traverse__': [], 'URL': [], 'locked_in_version__roles__': [], '_isBeingUsedAsAMethod_': []}, 'id': '000000000025', '_v_dm_': <Rack instance at 8649988>, '_v_writeableSlot': <PersistentMapping instance at 864ae78>, '_v_readableSlot': <PersistentMapping instance at 864ae78>, '_v_currentSheets': (<PropertySheet instance at 864a240>,), '_rackMounted': 1} ## getItem called second time ------------------------------------------- Wow! _v_attrCache stores a lot of various junk, including REQUEST!!! This disables, by the way, all the security mechanisms on traversed items! Phillip, would you be so kind and fix this? ;-) Thanks, Mike
Well, it should be:
################################################## # Add this to see what I mean
try : print "%s 'self'=%s" % ( key, slot.values()[0].__dict__ ) except : print "Nothing to print" # ###################################################
At 11:11 PM 6/22/00 +0800, mike wrote:
000000000025 'self'={'_v_attrCache': {'a_': [], 'filtered_manage_optionsisDocTemp': [], '_Change_permissions_Permission': [], 'MANAGE_TABS_NO_BANNER': [], 'im_func': [], '__allow_groups__': [], '_Manage_properties_Permission': [], 'tabs_path_infoisDocTemp': [], '__roles__': [], 'target': [], '_View_Permission': [], 'Zope-Version': [], 'locked_in_versionisDocTemp': [], 'n_': [], 'PATH_INFO': [], 'AUTHENTICATED_USER': [], 'manage_tabs_message': [], 'tabs_path_info__roles__': [], 'SCRIPT_NAME': [], 'REQUEST': [], '__bobo_traverse__': [], 'URL': [], 'locked_in_version__roles__': [], '_isBeingUsedAsAMethod_': []}, 'id': '000000000025', '_v_dm_': <Rack instance at 8649988>, '_v_writeableSlot': <PersistentMapping instance at 864ae78>, '_v_readableSlot': <PersistentMapping instance at 864ae78>, '_v_currentSheets': (<PropertySheet instance at 864a240>,), '_rackMounted': 1}
-------------------------------------------
Wow! _v_attrCache stores a lot of various junk, including REQUEST!!! This disables, by the way, all the security mechanisms on traversed items!
Phillip, would you be so kind and fix this? ;-)
This is not a bug, it's a feature. :) If you look closely at the dictionary, you will see it contains empty lists for all these items. These empty lists are the DataSkins.NOT_FOUND singleton, which caches the nonexistence of these attributes. This is not a security problem, nor any other kind of problem. It is instead a performance optimization which keeps the DataSkin from querying all the AttributeProviders every time a known-to-be-nonexistent attribute is looked for.
"Phillip J. Eby" wrote:
This is not a bug, it's a feature. :) If you look closely at the dictionary, you will see it contains empty lists for all these items. These empty lists are the DataSkins.NOT_FOUND singleton, which caches the nonexistence of these attributes. This is not a security problem, nor any other kind of problem. It is instead a performance optimization which keeps the DataSkin from querying all the AttributeProviders every time a known-to-be-nonexistent attribute is looked for.
There _IS_ a problem. Maybe _v_cachedAttr is not a guilty, but do you know it exists only in newly created objects and do _not_ exists in old?. Anyway, newly created DataSkin instances return wrong REQUEST (and other things) but _old_ retrieved ones work good. I tell you this because it is impossible to obtain AUTHENTICATE_USER from fresh DataSkins, so things like 'manage_tabs' just do not work properly. Try set up Rack for any real ZClass and you see this. If you'd like I send you complete test suite reproducing the situation. Mike
At 01:06 PM 6/23/00 +0800, mike wrote:
There _IS_ a problem. Maybe _v_cachedAttr is not a guilty, but do you know it exists only in newly created objects and do _not_ exists in old?.
The attribute cache is created only when used in a transaction, so if you retrieve a persistent object from a Rack and immediately dump its dictionary, the cache will not exist.
Anyway, newly created DataSkin instances return wrong REQUEST (and other things) but _old_ retrieved ones work good. I tell you this because it is impossible to obtain AUTHENTICATE_USER from fresh DataSkins, so things like 'manage_tabs' just do not work properly. Try set up Rack for any real ZClass and you see this.
I'm not currently seeing this, but the work Ty and I are doing with Racks at present involves objects which are not actually stored in the ZODB, so perhaps we're missing a bug with things that are stored in the ZODB, like the last one you found. But as far as I know, Rack.getItem() should always return an object whose acquisition context is the Specialist.
If you'd like I send you complete test suite reproducing the situation.
Please do. Thanks.
participants (2)
-
mike -
Phillip J. Eby