January 2002 - Zope-Dev

19 Jan '02

Could someone have a look at the following 'Boring' class with the security functionality added (as described in ZopeBook/6.Security and some other products). Could 'security' machinery be broken in Zope-2.4.1 ? It surely doesn't seem to work as adverised, on my machine at least (Debian Linux 2.2, Zope 2.4.1 (source release) python 2.1.0, linux2). Tell me if it works on your installation. Boring.py -------------------------------- __doc__ = "" __version__ = '0.1' import Globals from Globals import HTMLFile # fakes a method from a DTML file from Globals import MessageDialog # provid from Globals import Persistent # makes an object stick in the ZODB import OFS.SimpleItem import Acquisition import AccessControl.Role from AccessControl import ClassSecurityInfo READ_PERM = 'View Stuff' WRITE_PERM = 'Change Stuff' security = ClassSecurityInfo() manage_addBoringForm = HTMLFile('boringAdd', globals()) def manage_addBoring(self, id, title='', REQUEST=None): """Add a Boring to a folder.""" self._setObject(id, Boring(id, title)) if REQUEST is not None: return self.manage_main(self, REQUEST) class Boring( OFS.SimpleItem.Item, # A simple Principia object. Not Folderish. Persistent, # Make us persistent. Yaah! Acquisition.Implicit, # Uh, whatever. AccessControl.Role.RoleManager # Security manager. ): """Boring object. """ meta_type = 'Boring' # what do people think they're adding? manage_options = ( # what management options are there? {'label': 'Edit', 'action': 'manage_main'}, {'label': 'View', 'action': ''}, # defaults to index_html {'label': 'Security', 'action': 'manage_access'}, ) # NOTE: commented out following as it seem to conflict with # 'security.declareP...()' declarations later on # __ac_permissions__=( # what permissions make sense for us? # ('View management screens', ('manage_tabs','manage_main')), # ('Change permissions', ('manage_access',) ), # ('Change Borings' , ('manage_edit',) ), # ('View Borings', ('',) ), # ) def __init__(self, id, title=''): """initialise a new instance of Boring""" self.id = id self.title = title # SECURITY - ==================================================== # here I played with '#'s, then simply tried to access 'index_html' # after each security declaration, # as user 'Anonymous', and noted the results on same line. # 'NOT-WORKING' simply means not working as advertised (allowed access when # it shouldn't, and vice-versa). As you can see, there are too many # 'NOT-WORKING' results. Do you come to similar results? # My conclusion is that security declarations have no effect whatsoever, # whether I declare something, then its oposite, I end up with the same # result. This shouldn't be. security.setPermissionDefault(READ_PERM, ['Stuff Manager','Manager']) security.setDefaultAccess('deny') # <== NOT-WORKING # security.declarePrivate('index_html') # <== NOT-WORKING # security.declarePublic('index_html') # <== OK # security.declareProtected(READ_PERM, 'index_html') # <== NOT-WORKING index_html = HTMLFile('index', globals()) security.declarePublic('manage_main') # <== NOT-WORKING manage_main = HTMLFile('boringEdit', globals()) def manage_edit(self, title, REQUEST=None): " " self.title = title if REQUEST is not None: return MessageDialog( title = 'Edited', message = "Properties for %s changed." % self.id, action = './manage_main', ) Globals.InitializeClass(Boring) --------------------------------

2 3

Re: [Zope-dev] im_self of methods accessed via non trivial acquisition
by Phillip J. Eby 19 Jan '02

19 Jan '02

At 01:12 PM 1/18/02 +0100, Stefan Bund wrote: >"Phillip J. Eby" <pje(a)telecommunity.com> writes: > > > > Method rebinding is done only when an item is retrieved from the aq_self > > side, and only if im_self points to aq_self. If these conditions are met, > > a new binding is created which points to the acquisition wrapper. > > > > This is a feature, not a bug. If you rebind im_self on the aq_parent side, > > and your method assigns a value to an attribute of self, it will be > > assigned to the wrong object! It is safe in your example to bind m.im_self > > to B, because B.aq_base is f, the true self of m. But it is not safe to > > bind m.im_self to A, because A.aq_base is g -- another object altogether. > > > > I guess another way to look at it is that a method retrieved from an > > acquisition-wrapped object will always meet the condition that > > method.im_self.aq_base is the original object the method was retrieved > > from. This ensures that the method simply works with an > > acquisition-wrapped version of its original self. > >Of course, im_self cannot be A, that would be wrong, but as far as I >understand, it could be a *new* acquisition wrapper, something like /B >o A/ or even /[f] o A/: > >C--A--O--[a] >| | | >| | [b] >| | >| O--B--O--[c] >| | | | >| | | [d] >| | | >| | O--[e] >| | | >| | [f] >| | >| [g] >| >B--O--[c] >| | >| [d] >| >O--[e] >| >[f] > >(that's what I refer to in the definition of /C/). So if /C/ is one of >the aforementioned new wrappers, /C.aq_base/ is indeed [f] and >therefore, /C/ would be safe as im_self? > >Hmm. Is there another reasun, why method rebinding works the way it >does (returning a subtree and not a new acquisitionwrapper like >described above) or am I completely amiss? Beats me. I guess nobody's asked for the feature, and in any event it requires global knowledge of the tree structure that would be very difficult to code. The current behavior is a rule that is applied locally at each acquisition wrapper, and the wrappers don't know what wrapper is pointing to them, so it's really not practical for them to try and do something that "smart". It may also be that what you're asking for is a bad idea, in which case Jim Fulton can probably explain why. :)

1 0

Folding Zope Into an Install
by Noah Friedland 18 Jan '02

18 Jan '02

Fellow Zopers: I have recently completed a small app built on zope. I am trying to build an inno setup install script that will install zope silently (with a pre-determined master user/password). Any help on this would be greatly appreciated. --N

1 0

Re: [Zope] Error on install
by Eron Lloyd 18 Jan '02

18 Jan '02

Chris (or anybody else), Have you tried to install Beta4 using the linux binary package yet? I'm trying to write a patch against it but the installation does in fact bomb out each time I try to run it, even freshly untarred. The source TGZ works fine and dandy, however. It seems compilezpy.py has been dramatically changed since Beta3, as if to try and surpress the stdout messages. I'm going to try and break it down and find out where the exceptions are flagging, and also refactor my patch so it doesn't depend on the changes being made to compilezpy.py. I don't like wrapping a gag around code if I don't have to, and I'd rather this stuff be written to an install log or something. I-see-a-fishbowl-proposal-for-a-new-installer-ly yours, Eron On Thursday 17 January 2002 12:23 pm, you wrote: > Sure, go ahead! > > ----- Original Message ----- > From: "Eron Lloyd" <lloyd(a)lancaster.lib.pa.us> > To: <zope(a)zope.org> > Sent: Thursday, January 17, 2002 12:00 PM > Subject: Re: [Zope] Error on install > > > Ah hah! Yet another one...if no one objects, I'd like to try and patch > > compilezpy.py to ignore the test directory during install. I'll submit > > this > > > to the Collector when done. > > > > Eron > > > > On Thursday 17 January 2002 11:28 am, you wrote: > > > I am installing Zope and I get the bellow errors. > > > Could someone explain why I'm getting this? > > > > > > Thanks > > > > > > Allen May > > > MCSi Web Admin > > > 800.842.1702 x7628 > > > > > > > > > > > > Compiling python modules > > > File "/usr/zope/Zope-2.4.3-linux2-x86/lib/python2.1/test/nocaret.py", > > > line 2 > > > [x for x in x] = x > > > SyntaxError: can't assign to list comprehension > > > SyntaxError: from __future__ imports must occur at the beginning of the > > > file (test_future3.py, line 3) > > > SyntaxError: from __future__ imports must occur at the beginning of the > > > file (test_future4.py, line 3) > > > SyntaxError: from __future__ imports must occur at the beginning of the > > > file (test_future5.py, line 4) > > > SyntaxError: from __future__ imports must occur at the beginning of the > > > file (test_future6.py, line 3) > > > SyntaxError: from __future__ imports must occur at the beginning of the > > > file (test_future7.py, line 3) > > > > ------------------------------------------------------------------------- > >- > > - > > > >- > > > > _______________________________________________ > > Zope maillist - Zope(a)zope.org > > http://lists.zope.org/mailman/listinfo/zope > > ** No cross posts or HTML encoding! ** > > (Related lists - > > http://lists.zope.org/mailman/listinfo/zope-announce > > http://lists.zope.org/mailman/listinfo/zope-dev ) > > _______________________________________________ > Zope maillist - Zope(a)zope.org > http://lists.zope.org/mailman/listinfo/zope > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope-dev )

3 3

im_self of methods accessed via non trivial acquisition
by Stefan Bund 18 Jan '02

18 Jan '02

I have already posted this question on the main zope list but have not received a reply. I hope som Acquisition god is following this list to shed some light on this matter. If there is some kind of definite documentation for the acquisition machinery especially for how methods are fetched across acquisition, I would appreciate a pointer to that Documentation. I allready tried to digest the ZDG (chapter on Acquisition) and the information on the 'AcquisitionMadness' page <http://www.zope.org//Wikis/zope-dev/AcquisitionMadness>. Is there any more *definite* information on Acquisition apart from the source code. The problem is, I have a bit difficulty reading the source since it's an extension class :-(... But now on to the details of my original question (this is a copy of my post to the zope list): My question regards the details of how the contents of im_self of an acquired method is calculated by the acquisition machinery. To illustrate this, I will depict an acquisition tree using the following symbols: O -- an acquisition wrapper <upcase letter> -- an acquitsition wrapper named for further reference [<lowercase letter>] -- an object -- -- the aq_parent link | -- the aq_self link I will use the following acquisition tree for illustration (it resembles the tree I have in my application, I just reduced it to make my point) A--O--[a] | | | [b] | O--B--O--[c] | | | | | [d] | | | O--[e] | | | [f] | [g] (Note: some of the a-g's are identical, but for simpler reference from the text, i have named them all differently ...) In this representation, the acquisition order is from bottom to top. The bottom most object is /A.aq_base/. Acquisition along containment only produces horizontal lines of acquisition wrappers. let /m/ be a method of the objekt /f/. The expression of interest is x := A.m I would expect /x.im_self/ to be an acquisition wrapper C C := A.f where (as far as i understand the rules of acquisition) /C.aq_parent == A/ But instead displaying /x.im_self/ yields the acquisition tree rooted at /B/ !! I find this a bit disturbing. My question: 'Is it a *bug* or a *feature*?'. I hope, I made my point clear. I hope someone can shed light on this subject, Stefan.

2 1

Testing my product
by Adrian Hungate 18 Jan '02

18 Jan '02

I have had a lot of interest in a couple of my products, and I would like to ensure they are as stable as I can make them. I have heard a lot on here about unit-testing, is there a guide to creating unit-tests? Is there a procedure, or something to follow so that I can be sure I am testing "the right things"? Any help would be greatly appreciated. Adrian... -- Adrian Hungate All views expressed in this email are those of the whole world, however some people don't realise this yet.

3 2

Re: [Zope-dev] Zope is dying - Please, help!
by Chris McDonough 17 Jan '02

17 Jan '02

Since Zope 2.4 and/or Python 2.1. (there are bugs in both that cause crashes) ----- Original Message ----- From: "Rodrigo Leme de Mello" <rodrigo(a)idg.com.br> To: "Chris McDonough" <chrism(a)zope.com> Sent: Thursday, January 17, 2002 10:06 AM Subject: Re: [Zope-dev] Zope is dying - Please, help! > Thanks a lot for your answer men, i am desperate. i've put python 1.5.2 with zope 2.3.2 this was the last stable configuration. > > You told that is a problem with 2.4.3, this problem cames since when ? > > Best regards > > Rodrigo > > > > > The "compiler" module that ships with 2.4.3 "RestrictedPython" still has a > few bugs in it that could cause this behavior. 2.4.4 will be a bugfix > release to solve this. > > Please either wait for 2.4.4 or use 2.5beta4. > > - c > > ----- Original Message ----- > From: "Rodrigo Leme de Mello" <rodrigo(a)idg.com.br> > To: <zope-dev(a)zope.org> > Sent: Thursday, January 17, 2002 9:29 AM > Subject: [Zope-dev] Zope is dying - Please, help! > > > > Hi all, > > > > I am using python 2.1.2 with zope 2.4.3, i've compiled > python --without-py_malloc and also tried othe combinations as 2.1.1 with > > 2.4.2; 2.1.1 with 2.4.3 and still getting the same error. > > > > I'm not using pcgi, only zserver and apache with proxy pass. > > > > I do need to solve this. Does anybody have any idea what's going on? > > > > Any help will be welcome. > > > > Rodrigo > > > > ------ > > 2002-01-16T22:50:39 INFO(0) zdaemon zdaemon: Wed Jan 16 22:50:39 2002: > Houston, we have forked > > ------ > > 2002-01-16T22:50:39 INFO(0) zdaemon zdaemon: Wed Jan 16 22:50:39 2002: Hi, > I just forked off a kid: 19456 > > ------ > > 2002-01-16T22:50:39 INFO(0) zdaemon zdaemon: Wed Jan 16 22:50:39 2002: > Houston, we have forked > > ------ > > 2002-01-16T22:50:47 INFO(0) ZServer HTTP server started at Wed Jan 16 > 22:50:47 2002 > > Hostname: myhost > > Port: 1485 > > ------ > > 2002-01-16T22:53:03 ERROR(200) ZServer uncaptured python exception, > closing channel <zhttp_channel connected 200.162.45.200:1893 at > > 8de3234 channel#: 92 requests:> (socket.error:(32, 'Broken pipe') > [/home/zope/243/ZServer/medusa/asynchat.py|handle_read|83] > > [/home/zope/243/ZServer/medusa/http_server.py|recv|420] > [/usr/local/lib/python2.1/asyncore.py|recv|352]) > > ------ > > 2002-01-16T23:19:05 ERROR(200) ZServer uncaptured python exception, > closing channel <zhttp_channel connected 200.176.10.13:1143 at > > 8e57244 channel#: 2268 requests:> (socket.error:(32, 'Broken pipe') > [/home/zope/243/ZServer/medusa/asynchat.py|handle_read|83] > > [/home/zope/243/ZServer/medusa/http_server.py|recv|420] > [/usr/local/lib/python2.1/asyncore.py|recv|352]) > > ------ > > 2002-01-16T23:22:51 ERROR(200) zdaemon zdaemon: Wed Jan 16 23:22:51 2002: > Aiieee! 19456 exited with error code: 11 > > ------ > > 2002-01-16T23:22:51 INFO(0) zdaemon zdaemon: Wed Jan 16 23:22:51 2002: > Houston, we have forked > > ------ > > 2002-01-16T23:22:51 INFO(0) zdaemon zdaemon: Wed Jan 16 23:22:51 2002: Hi, > I just forked off a kid: 20180 > > ------ > > 2002-01-16T23:22:51 INFO(0) zdaemon zdaemon: Wed Jan 16 23:22:51 2002: > Houston, we have forked > > ------ > > 2002-01-16T23:23:00 INFO(0) ZServer HTTP server started at Wed Jan 16 > 23:23:00 2002 > > Hostname: myhost > > Port: 1485 > > ------ > > 2002-01-16T23:30:29 ERROR(200) ZServer uncaptured python exception, > closing channel <zhttp_channel connected 200.198.155.166:1026 at > > 8d6a84c channel#: 617 requests:> (socket.error:(32, 'Broken pipe') > [/home/zope/243/ZServer/medusa/asynchat.py|handle_read|83] > > [/home/zope/243/ZServer/medusa/http_server.py|recv|420] > [/usr/local/lib/python2.1/asyncore.py|recv|352]) > > ------ > > 2002-01-16T23:36:17 ERROR(200) ZServer uncaptured python exception, > closing channel <zhttp_channel connected 200.190.80.69:63362 at > > 8deb554 channel#: 984 requests:> (socket.error:(32, 'Broken pipe') > [/home/zope/243/ZServer/medusa/asynchat.py|handle_read|83] > > [/home/zope/243/ZServer/medusa/http_server.py|recv|420] > [/usr/local/lib/python2.1/asyncore.py|recv|352]) > > ------ > > 2002-01-16T23:37:23 ERROR(200) zdaemon zdaemon: Wed Jan 16 23:37:23 2002: > Aiieee! 20180 exited with error code: 11 > > ------ > > 2002-01-16T23:37:23 INFO(0) zdaemon zdaemon: Wed Jan 16 23:37:23 2002: > Houston, we have forked > > ------ > > 2002-01-16T23:37:23 INFO(0) zdaemon zdaemon: Wed Jan 16 23:37:23 2002: > Houston, we have forked > > ------ > > 2002-01-16T23:37:23 INFO(0) zdaemon zdaemon: Wed Jan 16 23:37:23 2002: Hi, > I just forked off a kid: 20423 > > ------ > > 2002-01-16T23:37:31 INFO(0) ZServer HTTP server started at Wed Jan 16 > 23:37:31 2002 > > Hostname: myhost > > Port: 1485 > > ------ > > 2002-01-16T23:52:00 ERROR(200) zdaemon zdaemon: Wed Jan 16 23:52:00 2002: > Aiieee! 20423 exited with error code: 11 > > ------ > > 2002-01-16T23:52:00 INFO(0) zdaemon zdaemon: Wed Jan 16 23:52:00 2002: > Houston, we have forked > > ------ > > 2002-01-16T23:52:00 INFO(0) zdaemon zdaemon: Wed Jan 16 23:52:00 2002: Hi, > I just forked off a kid: 20688 > > ------ > > 2002-01-16T23:52:00 INFO(0) zdaemon zdaemon: Wed Jan 16 23:52:00 2002: > Houston, we have forked > > > > > > _______________________________________________ > > Zope-Dev maillist - Zope-Dev(a)zope.org > > http://lists.zope.org/mailman/listinfo/zope-dev > > ** No cross posts or HTML encoding! ** > > (Related lists - > > http://lists.zope.org/mailman/listinfo/zope-announce > > http://lists.zope.org/mailman/listinfo/zope ) > > > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > >

1 0

Re: [Zope] Security Assertions
by Godefroid Chapelle 17 Jan '02

17 Jan '02

At 18:43 16/01/2002, you wrote: Sorry about cross-posting but I think the following info is worth reading for both zope-users and developers. >Note that up until Zope 2.5.0b4 there is a bug in the way module security >assertions are handled that makes it impossible to declare more than one >assertion without overwriting a previous assertion. It's not really a >"security hole", it's just annoying and clearly broken. I'd suggest that >you complain about this (or do it yourself) if you think a monkeypatch is >in order for Zope 2.3/2.4. I went to CVS and read AccessControl.SecurityInfo.py The code looked simple enough that I would take no risk by including it even if my understanding of the inner-working of Zope is still elementary. The following patch works to correct the problem for Zope 2.3.3. It does not seem to cause any other problem. # patch taken from Zope 2.5 from string import rfind # 1.5.2 syntax def ModuleSecurityInfo(module_name=None): if module_name is not None: modsec = _moduleSecurity.get(module_name, None) if modsec is not None: return modsec dot = rfind(module_name, '.') # 1.5.2 syntax if dot > 0: # If the module is in a package, recursively make sure # there are security declarations for the package steps # leading to the module modname = module_name[dot + 1:] pmodsec = ModuleSecurityInfo(module_name[:dot]) if not pmodsec.names.has_key(modname): pmodsec.declarePublic(modname) return _ModuleSecurityInfo(module_name) class _ModuleSecurityInfo(SecurityInfo): """Encapsulate security information for modules.""" in place of class ModuleSecurityInfo(SecurityInfo): """Encapsulate security information for modules.""" I do not know what you mean by a 'monkeypatch' but it is certainly worth it to add the patch to 2.3.x and 2.4.x branches. >Godefroid Chapelle wrote: > >> > Casey Duncan wrote: >> > >> > > So the following things don't work: >> > > >> > > from Products.Formulator.Form import FormValidationError >> > >> > Either Martijn or you need to add the following lines to a Product >> > __init__.py somewhere: >> > >> > from AccessControl import ModuleSecurityInfo >> > ModuleSecurityInfo('Products').declarePublic('Formulator') >> > ModuleSecurityInfo('Products.Formulator').declarePublic('Form') >> > >> ModuleSecurityInfo('Products.Formulator.Form').declarePublic('FormValidationError') >> >> > >> > Cheers, >> > >> > Evan @ Zope >> >>I added the above code in the corresponding __init__.py on my machine. >>Which works almost perfectly...: >>Further, I needed to be able to import : >>from Products.gvibDA.gvib.gvibExceptions import IntegrityError >> >>So I added the following code in gvibDA's __init__.py >>from Products.PythonScripts.Utility import allow_module, allow_class >>from AccessControl import ModuleSecurityInfo, ClassSecurityInfo >>from Globals import InitializeClass >>ModuleSecurityInfo('Products').declarePublic('gvibDA') >>ModuleSecurityInfo('Products.gvibDA').declarePublic('gvib') >>ModuleSecurityInfo('Products.gvibDA.gvib').declarePublic('gvibExceptions') >>ModuleSecurityInfo('Products.gvibDA.gvib.gvibExceptions').declarePublic('IntegrityError') >> >>from gvib.gvibExceptions import IntegrityError >>allow_class(IntegrityError) >> >>I get an 'Unauthorized: Formulator' error when accessing a script >>beginning with >>from Products.Formulator.Form import FormValidationError >>from Products.gvibDA.gvib.gvibExceptions import IntegrityError >> >>I suppose it has something to do with the creation of two instances of >>ModuleSecurityInfo('Products') but have no idea how to correct the problem. >>Any help would be appreciated. >> >>-- >> >>Godefroid Chapelle >>BubbleNet sprl >>rue Victor Horta, 18 / 202 >>1348 Louvain-la-Neuve >>Belgium >>Tel + 32 (10) 459901 >>Mob + 32 (477) 363942 >>TVA 467 093 008 >>RC Niv 49849 >> >>_______________________________________________ >>Zope maillist - Zope(a)zope.org >>http://lists.zope.org/mailman/listinfo/zope >>** No cross posts or HTML encoding! ** >>(Related lists - http://lists.zope.org/mailman/listinfo/zope-announce >>http://lists.zope.org/mailman/listinfo/zope-dev ) > > -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 18 / 202 1348 Louvain-la-Neuve Belgium Tel + 32 (10) 459901 Mob + 32 (477) 363942 TVA 467 093 008 RC Niv 49849

3 3

Zope is dying - Please, help!
by Rodrigo Leme de Mello 17 Jan '02

17 Jan '02

Hi all, I am using python 2.1.2 with zope 2.4.3, i've compiled python --without-py_malloc and also tried othe combinations as 2.1.1 with 2.4.2; 2.1.1 with 2.4.3 and still getting the same error. I'm not using pcgi, only zserver and apache with proxy pass. I do need to solve this. Does anybody have any idea what's going on? Any help will be welcome. Rodrigo ------ 2002-01-16T22:50:39 INFO(0) zdaemon zdaemon: Wed Jan 16 22:50:39 2002: Houston, we have forked ------ 2002-01-16T22:50:39 INFO(0) zdaemon zdaemon: Wed Jan 16 22:50:39 2002: Hi, I just forked off a kid: 19456 ------ 2002-01-16T22:50:39 INFO(0) zdaemon zdaemon: Wed Jan 16 22:50:39 2002: Houston, we have forked ------ 2002-01-16T22:50:47 INFO(0) ZServer HTTP server started at Wed Jan 16 22:50:47 2002 Hostname: myhost Port: 1485 ------ 2002-01-16T22:53:03 ERROR(200) ZServer uncaptured python exception, closing channel <zhttp_channel connected 200.162.45.200:1893 at 8de3234 channel#: 92 requests:> (socket.error:(32, 'Broken pipe') [/home/zope/243/ZServer/medusa/asynchat.py|handle_read|83] [/home/zope/243/ZServer/medusa/http_server.py|recv|420] [/usr/local/lib/python2.1/asyncore.py|recv|352]) ------ 2002-01-16T23:19:05 ERROR(200) ZServer uncaptured python exception, closing channel <zhttp_channel connected 200.176.10.13:1143 at 8e57244 channel#: 2268 requests:> (socket.error:(32, 'Broken pipe') [/home/zope/243/ZServer/medusa/asynchat.py|handle_read|83] [/home/zope/243/ZServer/medusa/http_server.py|recv|420] [/usr/local/lib/python2.1/asyncore.py|recv|352]) ------ 2002-01-16T23:22:51 ERROR(200) zdaemon zdaemon: Wed Jan 16 23:22:51 2002: Aiieee! 19456 exited with error code: 11 ------ 2002-01-16T23:22:51 INFO(0) zdaemon zdaemon: Wed Jan 16 23:22:51 2002: Houston, we have forked ------ 2002-01-16T23:22:51 INFO(0) zdaemon zdaemon: Wed Jan 16 23:22:51 2002: Hi, I just forked off a kid: 20180 ------ 2002-01-16T23:22:51 INFO(0) zdaemon zdaemon: Wed Jan 16 23:22:51 2002: Houston, we have forked ------ 2002-01-16T23:23:00 INFO(0) ZServer HTTP server started at Wed Jan 16 23:23:00 2002 Hostname: myhost Port: 1485 ------ 2002-01-16T23:30:29 ERROR(200) ZServer uncaptured python exception, closing channel <zhttp_channel connected 200.198.155.166:1026 at 8d6a84c channel#: 617 requests:> (socket.error:(32, 'Broken pipe') [/home/zope/243/ZServer/medusa/asynchat.py|handle_read|83] [/home/zope/243/ZServer/medusa/http_server.py|recv|420] [/usr/local/lib/python2.1/asyncore.py|recv|352]) ------ 2002-01-16T23:36:17 ERROR(200) ZServer uncaptured python exception, closing channel <zhttp_channel connected 200.190.80.69:63362 at 8deb554 channel#: 984 requests:> (socket.error:(32, 'Broken pipe') [/home/zope/243/ZServer/medusa/asynchat.py|handle_read|83] [/home/zope/243/ZServer/medusa/http_server.py|recv|420] [/usr/local/lib/python2.1/asyncore.py|recv|352]) ------ 2002-01-16T23:37:23 ERROR(200) zdaemon zdaemon: Wed Jan 16 23:37:23 2002: Aiieee! 20180 exited with error code: 11 ------ 2002-01-16T23:37:23 INFO(0) zdaemon zdaemon: Wed Jan 16 23:37:23 2002: Houston, we have forked ------ 2002-01-16T23:37:23 INFO(0) zdaemon zdaemon: Wed Jan 16 23:37:23 2002: Houston, we have forked ------ 2002-01-16T23:37:23 INFO(0) zdaemon zdaemon: Wed Jan 16 23:37:23 2002: Hi, I just forked off a kid: 20423 ------ 2002-01-16T23:37:31 INFO(0) ZServer HTTP server started at Wed Jan 16 23:37:31 2002 Hostname: myhost Port: 1485 ------ 2002-01-16T23:52:00 ERROR(200) zdaemon zdaemon: Wed Jan 16 23:52:00 2002: Aiieee! 20423 exited with error code: 11 ------ 2002-01-16T23:52:00 INFO(0) zdaemon zdaemon: Wed Jan 16 23:52:00 2002: Houston, we have forked ------ 2002-01-16T23:52:00 INFO(0) zdaemon zdaemon: Wed Jan 16 23:52:00 2002: Hi, I just forked off a kid: 20688 ------ 2002-01-16T23:52:00 INFO(0) zdaemon zdaemon: Wed Jan 16 23:52:00 2002: Houston, we have forked

2 1

unrestrictedTraverse and URLs ending in slash.
by Lennart Regebro 17 Jan '02

17 Jan '02

I quite often use URLs that end in a slash (in fact, I prefer it that way, since I then can add methods easily without having to care about if the url is the root '/' or another object). This got me into trouble, though, since unrestrictedtraverse can't handle URLs that end in a slash. I have patched it in my 2.3.4 installation so that it does, and think it would be a good idea to include this fix in Zope. What do you others think? >> OFS.Traversable Line 68: unrestrictedTraverse__roles__=() # Private def unrestrictedTraverse(self, path, default=_marker, restricted=0): if not path: return self get=getattr has=hasattr N=None M=_marker if type(path) is StringType: if (path[-1] == '/') and (path != '/'): path = path [:-1] # Handle URL's that end in a slash. path = split(path,'/') else: path=list(path)

1 0