July 2004 - Zope-Dev

TAL Hotfix 2004-07-13 for Zope 2.7.0, 2.7.1
by Fred Drake 13 Jul '04

13 Jul '04

This hotfix product fixes a security bug in Page Templates. This fix ensures that values substituted in named slots in translated elements are properly encoded. If encoding is not desired and the source of the replacement text is trusted, the "structure" modifier can be used with the tal:content or tal:replace attribute to explicitly disable encoding. Affected Versions This fix applies to Zope 2.7.0 and 2.7.1. Zope versions 2.7.2 and newer already contain this fix, and do not require this hotfix. Getting the Hotfix You can download the hotfix at: http://zope.org/Products/Zope/Hotfix_2004-07-13/Zope%202.7.0%20-%202.7.1/ The product contains a README.txt file with installation instructions. -Fred -- Fred L. Drake, Jr. <fred at zope.com> Zope Corporation

1 0

Log name variable and log procedure ( connection client )
by listador listas 12 Jul '04

12 Jul '04

This morning, I need to know which is the source IP where the client is connected from. I was found across the code but I cannot find anything, can anybody tell me where is the procedure (file) that calls the log procedure with the IPś client ? Thanks ______________________________________________ Yahoo! lanza su nueva tecnología de búsquedas ¿te atreves a comparar? http://busquedas.yahoo.es

2 1

"hasattr" geddon
by Dieter Maurer 12 Jul '04

12 Jul '04

Yesterday, I upgraded to Zope 2.7.1. Because several of our extensions broke, I have to look into detail at the changed and I saw that the "hasattr geddon" was started. Unfortunately, in a way that I feel as not optimal and error prone... In the module I saw, "if hasattr(obj, attr)" has been replaced by "if getattr(obj, attr, None)". This is neither general (in the special case, it was at least not false), nor optimal (in the special case, the boolean check was very expensive) nor clear. I propose to implement the "hasattr geddon" instead by a monkey patch for Python's builtin "hasattr". This has the following advantages: * no code changes needed with the exception of the monkey patch installation * the code is as clear as possible * the implementation can be made efficient and safe * no danger of missed "hasattr" occurrences Disadvantages: * Occasionally, a "hasattr" call might become slightly more inefficient than necessary (when "hasattr" operates on an object which is not persistent). * the usual problems with monkey patches (if someone else tries to monkey patch "hasattr", too) The "hasattr" replacement in Python's "__builtin__" could look like: _marker = [] def hasattr(obj, attr): return getattr(obj, attr, _marker) is not _marker Opinions? -- Dieter

5 9

2.7 series dropped PASV_FTP_PORTRANGE
by Brad Clements 12 Jul '04

12 Jul '04

In the 2.6 series I submitted a patch to support specifying the range of tcp ports to use on the server for pasv ftp transfers. I still need this functionality, but I see that the "environment variable hack" isn't in medusa/ftp_server.py I thought perhaps something in zope.conf would specify this, but it seems not to be there. In fact, I see no clean way to pass port range information from ZServer.FTPServer to medusa.ftp_server (hence why we used an environment variable hack in the past) For my use case, the pasv port range is always "near" the range used by the listening ftp daemon anyway, so a simple solution for me is to look at the control connection port and just find an open port that is "nearby". However the better solution, I suppose, is to allow the port range to be specified in zope.conf. But what's the best way (architecturally) to cleanly get this information into medusa's ftp_server.py module? -- Brad Clements, bkc(a)murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax http://www.wecanstopspam.org/ AOL-IM: BKClements

1 0

Zope 2.7.0 and Pythom Image Library
by Tor Oskar Wilhelmsen 09 Jul '04

09 Jul '04

Hi I'm trying to get the PIL(last version on python 2.3) working with Zope, but it seems that it's not working. I use the code: file = StringIO.StringIO(data) im = Image.open(file) im.show() where data is datafrom a blob in a db. This code is working outside Zope, but at once when i try to make it a product in Zope, I get this error: IOError: cannot identify image file Does anyone know what's wrong or what to do to make this work? Thanks for all help! Regards Tor Oskar Wilhelmsen

3 2

cStringIO strange errors
by Tor Oskar Wilhelmsen 09 Jul '04

09 Jul '04

Hi I'm using the code below to fetch an image from a database, and for inserting the image as an Image object in ZOPE. The strange thing is that the code causes python to crash, but sometimes it work (for 1 of 10 or something like that). Im using Python 2.3.3 for Windows and Zope 2.7.0 for windows. I don't get any indication about what causing the error, but testing leaves me with an error on the code below. Does anyone know what I have done wrong? imthumb = PIL.Image.open(StringIO(pic[3])) #pic[3] is the blob from the db imthumb.thumbnail(tsize) btfil = StringIO() imthumb.save(btfil,"JPEG") btfil.seek(0) #thumbnail title thumbnailtitle = str(pic[1]) self.manage_addProduct['OFSP'].thumbnails.manage_addImage(thumbnailid,btfil,thumbnailtitle,"","image/jpeg") btfil.close() - Tor Oskar Wilhelmsen

2 1

Streaming large files
by Thilo Staebler 09 Jul '04

09 Jul '04

hi! I have to stream large mpeg-files over http with range support. this works quite nice until the client seeks in the (media)player and the files aren't tooooo large, because zope caches the whole file... ...so each seek means streaming the whole file from the requested position till end *g* -> my RESPONSE object doesn't even know, that the player has seeked e.g. back to the beginning... is there a way to bypass the zope caching? and how do I know if the player has disconnected, so I can stop streaming? thanks in advance thilo

4 4

Re: [Zope-dev] Making a ZSQL.DA fully multi-threaded?
by sathya 09 Jul '04

09 Jul '04

sathya wrote: > we have been looking at psycopg for postgres. > zope opens atleast one connection per zope thread. I have obeserved the > same for mysql as well. Are you creating your own threads within zope ? > in which case you have to do the locking yourself > Brad Clements wrote: > >> I am using ZsapdbDA with SAPDB (now MaxDB) and have run into problems >> when Zope has more than one thread. >> >> The folks at SAP suggest that there should be one database connection >> per thread, rather than sharing one connection across threads. >> >> I haven't yet looked at the Zsapdb source, but I think it has only one >> connection for all threads. >> >> Is there a document somewhere that explains how to make variables >> "thread private" in Zope? I vaguely recall something about one cache >> per thread, or that variables are read- >> only shared unless updated by a thread, and then they're copied.. This >> is probably quite wrong, but obviously I just don't understand how >> data and threading works in Zope. >> >> So, I'm looking for a document that explains this clearly. How to have >> data that is not shared between threads (perhaps a kind of connection >> pool thingy). >> >> >> Also, I have other projects where I really want to have just one >> object of it's kind no matter how many threads. For example, gvibDA >> uses Thunked_TM for this, but that doesn't really work with ZSQLDA >> because I've seen that multiple connect calls are made, even with the >> THUNKED_TM. >> >> Is there a "Zen Of" document about this somewhere? >> >> Thanks >> >> >> > >

1 0

TALParser barfing on byte-order marked utf8 XML files.
by Romain Slootmaekers 09 Jul '04

09 Jul '04

Yo, We are using TAL for things other than ZPT. but are having problems with files that include a BOM preamble. the problem is that althought the underlying XML parser is capable of parsing these kind of files, TALParser initialises his parent without encoding (XMLParser.__init__(self) in TALParser.py line 27) Anyway, I have attached a small example (test.py + test.ml) that illustrates the problem with Zope 2.7.1. running the test gives: UnicodeEncodeError: 'ascii' codec can't encode character u'\ufeff' in position 0: ordinal not in range(128) which is perfectly logical: feff (the start of the bom preamble) is not ascii. chipping away the preamble (data=data[4:] ) gives problems further on in the file as the test example has some german characters (ä) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 50: ordinal not in range(128) which is also perfectly logical: ä has code 132. My question is simply: why is TALParser not taking the encoding into acount ? Is this deliberate, or is it an oversight ? Romain Slootmaekers. # # # from xml.dom.minidom import parseString import sys from TAL.TALParser import TALParser from TAL.TALInterpreter import TALInterpreter from TAL.DummyEngine import DummyEngine import StringIO import codecs print sys.getdefaultencoding() def readData(): f = open('test.xml','r') readerClass = codecs.getreader('utf8') print readerClass reader = readerClass(f) data = reader.read() f.close() print "size = %s" % len(data) return data def expand(xml): parser = TALParser() xml = xml[4:] parser.parseString(xml) program, macros = parser.getCode() engine = DummyEngine(0) out = StringIO.StringIO() interpreter = TALInterpreter(program,macros,engine,stream=out) interpreter() result = out.getvalue() return result data = readData() expanded = expand(data) document = parseString(expanded) print "ok"

1 0

AccessControl Problems on Mac OSX
by Terry Kerr 08 Jul '04

08 Jul '04

Hi, I seem to be having problems relating to AccessControl on MacOSX. I have a python product which I previously ran in Zope2.4.3/Python 2.1.3 and have upgraded it to run in Zope2.7.1/Python2.3.3. It runs fine on Linux and FreeBSD, however I get this traceback with some actions within the product on Mac OSX 10.1 Module Products.PageTemplates.Expressions, line 201, in __call__ Module Products.PageTemplates.Expressions, line 189, in _eval Module Products.PageTemplates.Expressions, line 145, in _eval __traceback_info__: shopper Module Products.PageTemplates.Expressions, line 340, in restrictedTraverse __traceback_info__: {'path': ['name'], 'TraversalRequestNameStack': []} SystemError: NULL result without error in PyObject_Call I narrowed this down to a guarded_getattr() problem in the AccessControl module. One thing I notice is that there is a C and a Python implementation of the access control stuff. If I explicitly set name='PYTHON' at the beginning of AccessControl/Implementation.py::setImplementation(), my product works fine, so I gather the problem is related to the C implementation. Has anyone experienced any similar problems on MacOSX? I notice this related issue in the zope collector, but it was rejected? http://zope.org/Collectors/Zope/232 Should I add another issue to the collector? terry

2 1