November 2001 - Zope-Dev

struggeling with a sessionbased LoginMethod
by Joachim Schmitz 08 Nov '01

08 Nov '01

Hi, I trying to develop a LoginMethod with the LoginManager product, which does not use the HTTP-authentication at all. But stores the user-information in a session, I am using CoreSessionTracking 0.9. If I call the loginForm directly, the user can login and can work in his session. He can logout and login again, everthing seams to work as exspected. the structure is like this: acl_users (default) AppFolder (not protected) acl_users (LoginManager) head foot index_html: <dtml-var head> <dtml-var content> <dtml-var foot> testFolder (protected) content When I now - as anonymous - call AppFolder/testFolder/content directly, which is not accessible to anonymous, the LoginManager-loginform pops up. But when I access AppFolder/testFolder, the default http-authorisation box pops up. When I test this with ZDebug, I get the information, that Zope is trying to publish index_html, and that user Anonymous is not allowed to access content. I debugged this, with the python-debugger and found, that only for the index_html, it is calling the validate-function of the LoginManager-acl_users. There the response.unauthorized is set to the correct loginForm. But further on the validate-functions of User.py are called. I posted this problem to the zpatterns-list, and got the following answer: Begin citation ------------------- Date: Tue, 6 Nov 2001 15:12:27 -0800 From: John Eikenberry <jae-zpat(a)kavi.com> To: zpatterns <zpatterns(a)eby-sarna.com> Subject: Re: [ZPatterns] still struggeling with a sessionbased LoginMethod I ran into the same problem. Turns out that Zope has 2 security mechanisms. The first checks the permissions on the published objects. The second is used when doing things like parsing the dtml. There is no way around it besides making sure that every folder that restricts access has an index_html in it. The index_html is looked for at publishing time and will trigger the loginForm. We had to go back to basic auth as we had just finished developing a whole publishing setup that was built around the idea of having 1 index_html at the top level. :P End citation ------------------- Can someone with the real Zope-Zen help ? Mit freundlichen Grüßen Joachim Schmitz AixtraWare, Ing. Büro für Internetanwendungen Hüsgenstr. 33a, D-52457 Aldenhoven Telefon: +49-2464-8851, FAX: +49-2464-905163

4 4

Re: [Zope-dev] Problem with Server -- Please Help
by Anthony Baxter 08 Nov '01

08 Nov '01

>>> Chris Bruce wrote > I didn't do anything. That is the scary part! > > I guess I will try and recompile. Are you sure someone didn't upgrade the version of 'python' that you're using? Or your path has changed so that it's finding a different version? -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

2 1

Deleting objects in BTreeFolder
by sean.upton＠uniontrib.com 08 Nov '01

08 Nov '01

Wondering why calling _delObject() in BTreeFolder, which inherits _delObject() from ObjectManager, doesn't work with BTreeFolder._getOb(), and I have to use BTreeFolder._delOb() to delete a contained object in a BTreeFolder. Is this incompatibilty by design? I run into trouble using _delObject (traceback #1 below), getting a deliberately raised AttributeError, but changing this to _delOb raises a key error when calling 'del tree[id]' on line 195. Thoughts? Sean ========================= Traceback #1: Traceback (innermost last): File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/lib/zope/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: Traversable) File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/lib/zope/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: rebuildDataFromSQL) File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: rebuildDataFromSQL) File /usr/lib/zope/lib/python/Products/a4Profiles/ZopeCirculation.py, line 169, in rebuildDataFromSQL (Object: Traversable) File /usr/lib/zope/lib/python/OFS/ObjectManager.py, line 340, in _delObject (Object: Traversable) File /usr/lib/zope/lib/python/Products/BTreeFolder/BTreeFolder.py, line 179, in _getOb (Object: Traversable) AttributeError: (see above) ========================= Traceback #2: Traceback (innermost last): File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/lib/zope/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: Traversable) File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/lib/zope/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: rebuildDataFromSQL) File /usr/lib/zope/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: rebuildDataFromSQL) File /usr/lib/zope/lib/python/Products/a4Profiles/ZopeCirculation.py, line 169, in rebuildDataFromSQL (Object: Traversable) File /usr/lib/zope/lib/python/Products/BTreeFolder/BTreeFolder.py, line 195, in _delOb (Object: Traversable) KeyError: (see above) ========================= Sean Upton Senior Programmer/Analyst SignOnSanDiego.com The San Diego Union-Tribune 619.718.5241 sean.upton(a)uniontrib.com =========================

1 0

Unauthorized - container has no security assertions
by Morten W. Petersen 07 Nov '01

07 Nov '01

Hi guys, I'm trying to develop a request session class (delivers session on a per-request basis), and during, get this error: Error type: Unauthorized Error value: Access denied for <method request_session.set of request_session instance at 0x9185e5c> because its container, <Products.warp_framework.request_session.request_session instance at 0x9185e5c>, has no security assertions. Traceback (innermost last): File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: abc) File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: abc) File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/OFS/DTMLMethod.py, line 195, in __call__ (Object: abc) File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/DocumentTemplate/DT_String.py, line 546, in __call__ (Object: abc) File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/Products/ZDebug/DTMLDebug.py, line 287, in debug_render_blocks File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/Products/ZDebug/DTMLDebug.py, line 237, in debugException File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/Products/ZDebug/DTMLDebug.py, line 285, in debug_render_blocks File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/DocumentTemplate/DT_Util.py, line 231, in eval (Object: get_request_session().set('katt', 'mjau')) (Info: get_request_session) File <string>, line 2, in f (Object: guarded_getattr) File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/AccessControl/DTML.py, line 101, in guarded_getattr (Object: abc) File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/AccessControl/ZopeGuards.py, line 122, in guarded_getattr File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/AccessControl/SecurityManager.py, line 149, in validate File /home/morten/zope_instances/Zope-2.4.2-src/lib/python/Products/ZDebug/DebugSecurityPolicy.py, line 185, in validate Unauthorized: (see above) The classes look like this: class request_session: """Class used for storing data on a per-request basis.""" def __init__(self): self.storage_ = {} def set(self, key, value): """Hook for setting values via DTML.""" self.storage_[key] = value __set_roles__ = None def __getitem__(self, key): return self.storage_[key] def __getattr__(self, name): try: return self.__getitem__(name) except KeyError: raise AttributeError, name class request_session_mixin: """Mixin class which will provide a request session.""" def get_request_session(self): """Returns the session for the request.""" try: return self.get_request()['request_session_'] except KeyError: self.get_request().set('request_session_', request_session()) return self.get_request_session() Any help much appreciated. Cheers, Morten -- About Thingamy: http://www.thingamy.com - For the CEO http://www.thingamy.org - The good stuff http://www.thingamy.net - Rants

1 0

Zope crash in select_trigger
by Mark Mitchell 07 Nov '01

07 Nov '01

Over the past few days, our Zope server has started crashing repeatedly, but unpredictably, with: Traceback (most recent call last): File "/usr/local/Zope/ZServer/PubCore/ZServerPublisher.py", line 97, in __init__ response._finish() File "/usr/local/Zope/ZServer/HTTPResponse.py", line 277, in _finish stdout.close() File "/usr/local/Zope/ZServer/HTTPResponse.py", line 334, in close Wakeup() File "/usr/local/Zope/ZServer/medusa/thread/select_trigger.py", line 74, in pull_trigger os.write (self.trigger, 'x') OSError: [Errno 32] Broken pipe I see some other similar reports in the archives, but no fixes. Does anybody have ideas about what is causing this problem? -- Mark Mitchell mark(a)codesourcery.com CodeSourcery, LLC http://www.codesourcery.com

7 11

Re: [Zope-dev] Problem with Server -- Please Help
by Chris Bruce 07 Nov '01

07 Nov '01

I didn't do anything. That is the scary part! I guess I will try and recompile. Thanks. --- Jim Washington <jwashin(a)vt.edu> wrote: > Chris Bruce wrote: > > > Hi all. I am trying to start the Zope 2.3 server and all of a > sudden > > it will not start. It is producing the following in the zserver1 > > logfile: > > > > WARNING: Python C API version mismatch for module ExtensionClass: > > This Python has API version 1009, module ExtensionClass has > version > > 1010. > > WARNING: Python C API version mismatch for module zlib: > > This Python has API version 1009, module zlib has version 1010. > > WARNING: Python C API version mismatch for module ExtensionClass: > > This Python has API version 1009, module ExtensionClass has > version > > 1010. > > WARNING: Python C API version mismatch for module zlib: > > This Python has API version 1009, module zlib has version 1010. > > > > > > Any idea what this means? > > > Hi, Chris > > Your zope was compiled with a different version of python than your > > current version of python. Did you just upgrade or downgrade python? > You may need to recompile your zope (w_pcgi.py or wo_pgci.py) ... or > you > may need to change your startup scripts to invoke the python with > which > zope was compiled. > > -- Jim Washington > > __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com

1 0

Problem with Server -- Please Help
by Chris Bruce 07 Nov '01

07 Nov '01

Hi all. I am trying to start the Zope 2.3 server and all of a sudden it will not start. It is producing the following in the zserver1 logfile: WARNING: Python C API version mismatch for module ExtensionClass: This Python has API version 1009, module ExtensionClass has version 1010. WARNING: Python C API version mismatch for module zlib: This Python has API version 1009, module zlib has version 1010. WARNING: Python C API version mismatch for module ExtensionClass: This Python has API version 1009, module ExtensionClass has version 1010. WARNING: Python C API version mismatch for module zlib: This Python has API version 1009, module zlib has version 1010. Any idea what this means? __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com

2 1

RE: [Zope-dev] Opinions wanted: clean installation (was distribut ion)
by Toby Dickenson 07 Nov '01

07 Nov '01

> and > results in > too little of an integrity gain to make it the default. That statement gave me something to think about. Indeed, as I had described it there is little to be gained. In practice, I share administrative users between instances. The security gain is that different instances can use the same product source code, without the risk of a compomise spreading between instances. >> Indeed, I dont think that works in your proposal. Zope need to write >> inituser while it is running, if that file is ever to be of use. I also >> think its unlikely we would want to lock the 'access' file so tightly. > Yes, I'd forgotten about that. inituser is just deleted after it's > merged into the ZODB, right? Then it should probably go somewhere in > the VARDIR/zope/INSTANCE hierarchy. It sounds like almost everything is going into VARDIR now, except the source which is elsewhere. If the data.fs is stored in a directory VARDIR/zope/INSTANCE/var then the whole setup looks very much like the traditional INSTANCE_HOME system ;-) > I am thinking of making a wiki re all this... good idea? mmmmm.

3 5

Opinions wanted: clean distribution
by Behrens Matt - Grand Rapids 07 Nov '01

07 Nov '01

I'm experimenting with a few ideas for a "clean distribution" of Zope; i.e. one that builds on the INSTANCE_HOME concept to produce a production-ready layout for UNIX-like systems. My hope is that it will someday make life a hell of a lot easier for Zope packagers (such as myself) as well as end-users. I'd love for the Zope install script to create this layout by default, and am certainly willing to dedicate code to the effort. I'm looking at a software home directory like this: BINDIR zopectl zopeinst LIBEXECDIR pcgi-wrapper LIBDIR zope (eveything from lib/python) Products Extensions [1] ZServer [1] inst [1] utilities [1] ETCDIR zope access inituser instances [2] VARDIR zope INSTANCE [2] db [3] Data.fs (et al.) run [4] *.pid gadfly [3] [5] [1] I am not sure if putting these folders here clashes with anything. Extensions, especially, I am worried about. [2] Instances should be named and built by 'zopeinst', which takes care of reasonably secure default permissions. The 'instances' file would list these along with start parameters and flags that zopectl understands; zopectl could be used to shutdown/startup zope instances in system startup/shutdown scripts this way. [3] These directories should be readable and writable only by the user who runs Zope. [4] This directory, if Zope is started as root, should be writable only by root. [5] Other instance-specific files such as Zope.cgi would live here. start/stop duties would be taken over by zopectl. The top level directories (BINDIR, LIBEXECDIR, LIBDIR, ETCDIR, VARDIR) would be configured at install time but would probably default to /usr/local/bin, /usr/local/libexec (or sbin for non-BSDers), /usr/local/lib, /usr/local/etc, /usr/local/var. I'm really looking for compatibility issues that anyone has or any suggestions for improvement. I plan to make a proposal out of this eventually. Please make sure you cc me at home (matt(a)zigg.com) on replies. -- Matt Behrens <matt.behrens(a)kohler.com> System Analyst, Baker Furniture

6 7

Re: [Zope-dev] Zope crash in select_trigger
by Anthony Baxter 07 Nov '01

07 Nov '01

One of the uglies we found was that an extension did a os.popen() or suchlike, and the sigchild was getting delivered to the main thread - this was hitting the select at a bad place and causing brokenness. The patch we were using was something like the following (this is against ZServer/medusa/asyncore.py) hth, Anthony --- asyncore.py 2000/01/11 09:33:18 1.1 +++ asyncore.py 2000/05/18 03:48:19 1.2 @@ -52,7 +52,16 @@ if s.writable(): w.append (s) - (r,w,e) = select.select (r,w,e, timeout) + try: + (r,w,e) = select.select (r,w,e, timeout) + # on solaris, something causes a signal to get here + # sometimes - sigpipe? sigchld? stupid truss doesn't + # say - so this is the approach we take. ow. + except KeyboardInterrupt: + raise # convenience when running interactively + except: + print "select interrupted!" + return for x in r: try: >>> Andre Schubert wrote > Hi, > > I'am using DA's especially the ZPsycopgDA. > We use our DB very much. > We have change from ZPygres to ZPsycopg the last month, but the errors > always occur. > > question: do have any other problems with Zope-DAs, i had one with > DB-Authentication??? > > thanks as > > Dario Lopez-Kästen schrieb: > > > > From: "Andre Schubert" <andre.schubert(a)geyer.kabeljournal.de> > > > our Zope has the same problem, he dies unexpectly with Error-Code 13. > > > Can i use the pymalloc-hint for me... RedHat 6.2 Immunix and Zope 2.3.3 > > > and python 1.5.2. > > > > the --without-pymalloc thing is only relevant to Python 2.1, IIRC, thus onl y > > if you use newr Zopes. > > > > A question: you that are experiencing these problems, are you using databas e > > adapters? > > if so, what adapters? How much do you make use of them? > > > > > And are there some docs or how-tos about the pymalloc-hint?????? > > > > the INSTALL doc in the Python src has some info. I got help from Steva A wh o > > pointed me in the right direction. > > > > /dario > > > > _______________________________________________ > > 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 ) > -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0