August 2004 - Zope-Dev

Protected session items?
by Lennart Regebro 27 Aug '04

27 Aug '04

In TransientObject __guarded_setitem__ is just set to __setitem__. This means, that everything you set in the session dictionary is changeable through user code. Is there a good reason for this? I think it would be nice if I could set secret things in the session, mainly authentication information. If i do this currently, any user code can change it, which isn't exactly safe. REQUEST.SESSION['__ac_username'] = 'root' Ooops! :) This change: def __guarded_setitem__(self, k, v): if k[0] == '_': raise SomeThingOrAnotherError self.__setitem__(k, v) Fixes that. Then you can only set it from protected code. Is there some reason why this is NOT a good idea? //Lennart

4 6

APE leaving SQL transactions open
by Paolo Bizzarri 26 Aug '04

26 Aug '04

Hi all. We're making our first experiments with APE. The environment is Zope 2.7.1 on Linux. We're using APE 0.8.1. A problem we encountered is that APE leaves the final db transaction neither commited nor aborted, in the normal behaviour. I mean, this is what is going on here: 1) I create a new object under the /sql folder 2) all the required SQL transaction is done, and data is commited on the DB 3) a new SQL transaction begins (corresponding to the new zope transaction) for the new page but this last SQL transaction is never closed. The short story is that you can see the (in)famous "idle in transaction" message on a ps axf on the box Since we had very bad experience with the "idle in transaction" in the past, we would like to know if this is a known behaviour, if it is safe, and why. Thank you all. Regards Paolo -- Paolo Bizzarri - President - Icube S.r.l. Address: Via Ridolfi 15 - 56124 Pisa (PI), Italy E-mail: p.bizzarri(a)icube.it Web: http://www.icube.it Phone: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588

2 4

how to start workflow instance on another zope serverwith SOAP?
by Aruna Kathiriya 25 Aug '04

25 Aug '04

Hi, I am very new to open source. I am trying to start an instance of a workflow on a Zope server from another Zope server. I did successfully with XML-RPC call but I need to do it with SOAP. I am note sure weather I can do it or not. I am running two Zope servers on my local m/c on 2 different ports. One is 8080 and 2nd one is 8090. On 8080: Page_template : SoapTest2 <html> <body> Activate instance at other server: <span tal:define= " l_user python:request.get('AUTHENTICATED_USER');"> <form action="SubmitNewSoapTest2" method="post" enctype="multipart/form-data"> <input type="file" name="p_file"><br> <input type="hidden" name="user" tal:attributes= "value python:l_user;"> <input type="hidden" name="password" value="Aruna"> <input type="submit" value="Submit"> </form> </span> </body> </html> SubmitNewSoapTest2 is external method. the python script for that is testTrigger as follow. from SOAPpy import SOAPProxy import xml.sax def startTestInstance2(self,p_file,user,password): myFile =p_file.read() # parser = xml.sax.make_parser() # parser.parse(myFile) url = 'http://localhost:8090/' namespace = 'urn:xmethods-testInstance' server = SOAPProxy(url, namespace) return server.SoapTestInstance(p_file,user,password) On 8090: I have a python script SoapTestInstance having 3 parameters (p_file,user,password) and following code. wf = context.TestFlow i_id = wf.addInstance('TestProcess', '', '', '', 0) instance = wf.getInstance(i_id) instance.manage_addFile(id="theFile", file=p_file, title="") wf.startInstance(i_id) wf.activateWorkitem(i_id, '0', user ) wf.completeWorkitem(i_id, '0') return "created new instance with code %s" % i_id It gives me following error. Error Type: SAXParseException Error Value: http://www.w3.org/TR/REC-html40/loose.dtd:31:2: error in processing external entity reference Any help will be appriciated. I already stucked here.. Thanks Aruna Kathiriya Sr.Consultant CIGNEX Technologies, Inc T: 408.501.0455 x 306 F: 408.273.6785 C: 408.896.1330 E: harish(a)cignex.com U: www.cignex.com "Implement IT Right"

1 0

Preventing scripts from being called directly
by Dario Lopez-Kästen 25 Aug '04

25 Aug '04

Hello, I am trying to prevent PythonScripts from being called directly TTW. Is there a better way of doing this than the following code being called at the very begining of the script? if script.getPhysicalPath() = context.REQUEST.PUBLISHED.getPhysicalPath(): raise "UnAuthorisedOrSimilar" Thanks, /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech.

3 5

Transaction problems and publisher
by Florent Guillaume 24 Aug '04

24 Aug '04

I've reopened bug 789 (http://collector.zope.org/Zope/789) because we observed problems in Zope 2.7.2 with transaction abort by the publisher. The problems can make objects disappear or provoke POSKeyErrors. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 71 59 http://nuxeo.com mailto:fg@nuxeo.com

2 1

Re: [Zope-dev] Patch: let non-seekable streams be input for ZPublisher (updated)
by Ames Andreas (MPA/DF) 24 Aug '04

24 Aug '04

Hello, Leonardo Rochael Almeida wrote: > Yes, if you file a feature request on the bug collector, which can > be found at: I've put the most recent version of the patch to http://collector.zope.org/Zope/1472. cheers, andreas

1 0

Re: [Zope-dev] Patch: let non-seekable streams be input for ZPublisher (updated)
by Ames Andreas (MPA/DF) 23 Aug '04

23 Aug '04

Hello, Dieter Maurer wrote: > Maybe, I have a much simpler solution: > > Something in ZServer makes all file fields seekable by > delivering them through some temporary (either a StringIO > or a temporary file). > > Maybe, you could do the same for your requests? Yes, I could. But trying to avoid it was the very reason I tried to patch HTTPRequest for. What you propose is what the HTTPServer does for instance. I have at least two objections: 1) For big requests (big means some hardcoded threshold) HTTPServer buffers the request on disk. Then ZPublisher creates a FieldStorage instance which will write the request once again to disk. And that also means the request is read from disk several times. That's a bit too much blocking disk I/O in a production webserver for my liking. And that's not counting retries; each retry will add another pair of blocking disk I/O in the current implementation. What I'm trying to do is: - avoid unneeded disk I/O in retries - make it possible that self.stdin in HTTPRequest can be non-seekable such that it doesn't have to be buffered on disk before FieldStorage is created (and does exactly that buffering). 2) I'm convinced that the one and only ZServer thread should do without any blocking (I/O) call (besides select() that is) and I want AJPServer also be an experiment to see if this improves performance. cheers, andreas

1 0

Re: Debian and Zope
by Thaddeus H. Black 23 Aug '04

23 Aug '04

This question regards the code in Zope's zpasswd.py. If you know zpasswd.py or are involved in Debian, please reply. Debian GNU/Linux 3.1 releases soon. The Debian Zope package (actually the Debian `zopectl' package) has what Debian calls a Release Critical Bug open against it [http://bugs.debian.org/251038] Normally, Debian's Zope maintainer would handle such a bug, but the maintainer seems to be inactive this year, so it falls to me to fix it. This is okay. The maintainer's work in earlier years is appreciated. The trouble is, I do not use Zope myself, so I am fixing the bug with limited understanding of the potential consequences of the fix. The part of the Debian fix which affects your Zope source is in zpasswd.py. At present, a user can invoke zpasswd in either of two ways: (1) without command-line options, in which case zpasswd prompts the user on tty for username and password; or (2) with username and password supplied on the command line. How the user cannot presently invoke zpasswd is (3) with username supplied on the command line, so that zpasswd prompts the user on tty for a password only. The Zope installation procedure on Debian requires option (3). With (3), I can cleanly eliminate the Release Critical Bug now and prevent Zope from being dropped from Debian 3.1. Thus I am adding (3) to Debian Zope. Question, please. Does my addition create some subtle problem I should know about? If Zope were coded perfectly cleanly, then the addition of option (3) should create no problem; but you and I have both done enough coding to realize that old code can sometimes depend in strange ways on the odd behavior of even older code. With my small addition, zpasswd now correctly handles (3). Is this okay, or can you think of something specific it might break, something I might not have noticed? I have checked everything I know how to check, but I do not know Zope; you guys do. Regrettably, Zope's public SVN seems to be down as I write these words, so in the unlikely event that someone had already added option (3) to zpasswd.py, I would not know about it. I do understand and respect that, like any good free-software developers, you will probably all want me to update Debian Zope now to Zope's latest version! To this, I must plead that such an update far exceeds the limits of my Zope ignorance (also, it would violate Debian Project policy, which permits me minimally to fix a Release Critical Bug for an inactive maintainer but forbids me from unilaterally hijacking his Debian package). The matter at hand now is not how to include the latest Zope (it is not Debian's usual practice to include the very latest software in any event) but rather how to keep Zope in Debian at all. This is a good cause and I am pleased to help. I do not regularly subscribe to zope-dev, so please copy your reply to me and to 251038(a)bugs.debian.org (the latter automatically attaches your reply to the relevant official Debian bug report, #251038). If there were no reply, this would be okay; I would just assume that my fix were as good as it seems to be, and would proceed accordingly. Please reply by 23 August. If any active Zope developer on this list also happens to be a registered Debian Developer, he is asked to step in and take charge of Debian bug #251038 from here: one can find my full zopectl/zope Debian patch attached to the Debian bug report. Otherwise, thank you for your attention in this matter. If you want my patch to zpasswd.py, here it is. You probably want to apply it to your own SVN Zope source. diff -u zope-2.6.4/zpasswd.py zope-2.6.4.new/zpasswd.py --- zope-2.6.4/zpasswd.py 2004-08-03 20:34:53.000000000 +0000 +++ zope-2.6.4.new/zpasswd.py 2004-08-03 18:49:11.000000000 +0000 @@ -87,6 +87,16 @@ import do; do.ch(ac_path, user, group) +def get_password(): + while 1: + password = getpass.getpass("Password: ") + verify = getpass.getpass("Verify password: ") + if verify == password: + return password + else: + password = verify = '' + print "Password mismatch, please try again..." + def main(argv): short_options = ':u:p:e:d:' @@ -150,7 +160,10 @@ # Verify that we got what we need if not username or not password: - raise "CommandLineError" + if username: + password = get_password() + else: + raise "CommandLineError" access_file.write(username + ':' + generate_passwd(password, encoding) + @@ -163,14 +176,7 @@ if username != '': break - while 1: - password = getpass.getpass("Password: ") - verify = getpass.getpass("Verify password: ") - if verify == password: - break - else: - password = verify = '' - print "Password mismatch, please try again..." + password = get_password() while 1: print """ -- Thaddeus H. Black 508 Nellie's Cave Road, Blacksburg, Virginia 24060, USA; +1 540 961 0920, t(a)b-tk.org

3 4

Re: [Zope-dev] Re: Debian and Zope
by Chris Withers 23 Aug '04

23 Aug '04

Thaddeus H. Black wrote: >>Can you tell us who that maintainer is? > > Luca De Vitis <luca(a)debian.org>. Last known > Zope activity: 4 Nov 2003. Hmmm, don't know him. Anyone else know him? Oh well, I guess we'll just have to wait for someone with the necessary Zope and Debian Zen to emerge :-/ cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

1 0

More unit test questions
by Lennart Regebro 20 Aug '04

20 Aug '04

OK, I got test.py running. But if I run bin/python test.py Products it will happily try to run the tests in all products. But if I type bin/python test.py Products/Productname It will find no tests at all. bin/python test.py Products/Productname/tests is no better. BUT! If I type bin/python test.py lib/python/Products/ZCTextIndex it does find the tests for ZCTextIndex. In short: Heuh? What are the difference that makes it impossible to test just one products unit test if it's located in Products instead of lib/python/Products. Or is there a difference in how the CMF tests are written? Anybody know?

3 3