April 2004 - Zope-Dev

RE: [Zope-dev] zope 2.7.0: no tracebacks produced
by Mika, David P (Research) 21 Apr '04

21 Apr '04

Thanks! I have found the error_log object in the ZMI too. Dave -----Original Message----- From: Willi Langenberger [mailto:wlang@wu-wien.ac.at] Sent: Tuesday, April 20, 2004 6:41 PM To: Mika, David P (Research) Cc: 'zope-dev(a)zope.org' Subject: Re: [Zope-dev] zope 2.7.0: no tracebacks produced According to Mika, David P (Research): > I am making a big upgrade and moving my products from 2.3.1 on HP-UX > to 2.7.0 on windows 2000 and can't get zope to produce any tracebacks > when it encounters errors. I've checked all the log files and monitor > stdout > to no avail. All I get is a brief html message with error type and value > and > instructions to check the error log. from Zope-2.7.0/lib/python/ZPublisher/HTTPResponse.py: # Enable APPEND_TRACEBACKS to make Zope append tracebacks like it used to, # but a better solution is to make standard_error_message display error_tb. APPEND_TRACEBACKS = 0 \wlang{} -- Willi.Langenberger(a)wu-wien.ac.at Fax: +43/1/31336/9207 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria

1 0

Re: [Zope3-dev] Proposal: Rename zope package
by Troy Farrell 21 Apr '04

21 Apr '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote: | |> Jim Fulton wrote: |> ... |> I've gotten enough negative feedback to "z", that I've added an |> alternative 4 |> to the proposal: |> |> 4. Rename the Zope package to Zope2 and provide a legacy Zope |> package | | -1, for reasons I've stated before. This is Zope 3's problem; we | *can't* inflict the pain on the large set of installed production | servers to favor "cleanliness" for the one only installed by | arrow-backed pioneers. We would be *much* better off with the status | quo ante than with such a "solution". | | Tres. - -1 on alternative 4. This lurker is with Tres. This is a Z3 challenge. I wonder how many part-time Zope 2 admins will be happy about making this change and having to retest code they've inherited from some contract developer. As a developer, this change is attractive. However, I can't see it as feasible for the real world. Troy - -- And the glory of the LORD shall be revealed, and all flesh shall see it together: for the mouth of the LORD hath spoken it. Isaiah 40.5 0xD3BDCA53 http://tjf.us/public.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAhmbnAykmMtO9ylMRAkcRAJwP4FBU5oosHN/3rESobu2ow7XUiwCff0Gv yzgfB6TI6uOmDFA3Z3zKn78= =saog -----END PGP SIGNATURE-----

1 0

[patch] More secure cookie crumbler?
by Chris Withers 21 Apr '04

21 Apr '04

Hi Shane and zope-dev, I think the attached patch (against CookieCrumbler 1.1) makes CookieCrumbler a little more secure. It makes CookieCrumbler not store the user's password and username on the browser side and rotates the token stored on the browser side ever 10 seconds or time between request, whichever is longer. It also provides a session timeout controlled by the server. I thought I'd post it here so people could have a look and let me know what you think. If the patch is sound, it'd be great to see the patch make it into the next release of CookieCrumbler, and maybe the CMF and Plone HEADs? cheers, Chris PS: To make cookie auth properly secure, you really need to be working over SSL only, and in addition, you should tweak CookieCrumbler further so that it sets the secure session bit, meaning your sessions should only get returned over a secure connection... mindyou, to get basic auth to be even vaguely secure, you also need to be working over SSL ;-) (and you should never let your users change their password without some other form of authentication, or at the very least making them enter their old password in the same atomic operation as setting their new password ;-) -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk Index: CookieCrumbler.py =================================================================== --- CookieCrumbler.py (revision 207) +++ CookieCrumbler.py (working copy) @@ -24,17 +24,39 @@ from AccessControl import getSecurityManager, ClassSecurityInfo, Permissions from ZPublisher import BeforeTraverse import Globals +import threading from Globals import HTMLFile from zLOG import LOG, ERROR from ZPublisher.HTTPRequest import HTTPRequest from OFS.Folder import Folder +from BTrees.OOBTree import OOBTree +from time import time - # Constants. ATTEMPT_NONE = 0 # No attempt at authentication ATTEMPT_LOGIN = 1 # Attempt to log in ATTEMPT_RESUME = 2 # Attempt to resume session +# set this to 0 to get "old style" sessioning +more_secure = 1 + +# the default store of session information, for "more secure" sessioning +lock = threading.Lock() +session2ac = OOBTree() +session2reset = OOBTree() +time2session = OOBTree() +import random +try: + jn = random.randint(0,2L**160) + def getRandom(): + return hex(random.randint(0,2**160))[2:-1] +except: + # python < 2.3 + jn = random.random() + def getRandom(): + return str(random.random())[2:] +random.jumpahead(jn) + ModifyCookieCrumblers = 'Modify Cookie Crumblers' ViewManagementScreens = Permissions.view_management_screens @@ -115,9 +137,74 @@ return getattr( self.aq_inner.aq_parent, name, default ) security.declarePrivate('defaultSetAuthCookie') - def defaultSetAuthCookie( self, resp, cookie_name, cookie_value ): - resp.setCookie( cookie_name, cookie_value, path=self.getCookiePath()) + security.declarePrivate('defaultGetAuthCookie') + security.declarePrivate('defaultExpireOldSessions') + if more_secure: + def defaultSetAuthCookie( self, resp, cookie_name, cookie_value ): + session = getRandom() + global session2ac + global session2reset + global time2session + lock.acquire() + session2ac[session]=cookie_value + # tweak this for session expirey time + t = time() + expiretime = t+20*60 # 20 mins + if not time2session.has_key(expiretime): + time2session[expiretime]=[] + time2session[expiretime].append(session) + # cookie reset time (this allows rotating session values + # while still letting simultaneous requests such as ZMI + # keep working) + session2reset[session]=t+10 #10 secs + lock.release() + resp.setCookie( cookie_name, session, path=self.getCookiePath()) + def defaultGetAuthCookie( self, resp, cookie_name, acc ): + lock.acquire() + ac = session2ac.get(acc,None) + if ac is None: + lock.release() + method = self.getCookieMethod( 'expireAuthCookie' + , self.defaultExpireAuthCookie ) + method( resp, cookie_name=self.auth_cookie ) + return None + t = session2reset[acc] + lock.release() + if t<time(): + del session2ac[acc] + del session2reset[acc] + method = self.getCookieMethod( 'setAuthCookie' + , self.defaultSetAuthCookie ) + method( resp, cookie_name, ac ) + return ac + + def defaultExpireOldSessions(self): + global session2ac + global session2reset + global time2session + expiretime = time() + lock.acquire() + for t,sessions in time2session.items(0,expiretime): + for session in sessions: + try: + del session2ac[session] + del session2reset[session] + except KeyError: + # it's already gone + pass + del time2session[t] + lock.release() + else: + def defaultSetAuthCookie( self, resp, cookie_name, cookie_value ): + resp.setCookie( cookie_name, quote(cookie_value), path=self.getCookiePath()) + + def defaultGetAuthCookie( self, acc ): + return unquote(acc) + + def defaultExpireOldSessions(self): + pass + security.declarePrivate('defaultExpireAuthCookie') def defaultExpireAuthCookie( self, resp, cookie_name ): resp.expireCookie( cookie_name, path=self.getCookiePath()) @@ -167,15 +254,22 @@ path=self.getCookiePath()) method = self.getCookieMethod( 'setAuthCookie' , self.defaultSetAuthCookie ) - method( resp, self.auth_cookie, quote( ac ) ) + method( resp, self.auth_cookie, ac ) self.delRequestVar(req, self.name_cookie) self.delRequestVar(req, self.pw_cookie) elif req.has_key(self.auth_cookie): + # take the opportunity to potentially delete expired sessions + method = self.getCookieMethod( 'expireOldSessions' + , self.defaultExpireOldSessions ) + method() # Attempt to resume a session if the cookie is valid. # Copy __ac to the auth header. - ac = unquote(req[self.auth_cookie]) - if ac and ac != 'deleted': + acc = req[self.auth_cookie] + if acc and acc != 'deleted': + method = self.getCookieMethod( 'getAuthCookie' + , self.defaultGetAuthCookie ) + ac = method( resp, self.auth_cookie, acc) try: decodestring(ac) except:

10 24

zLOG is dead
by Fred Drake 21 Apr '04

21 Apr '04

============ zLOG is dead ============ The zLOG package used for logging throughout ZODB, ZEO, and Zope 2 has been declared obsolete. All logging for Zope products will use the logging package from Python's standard library. The zLOG package still exists in Zope 2 and the separate package for ZODB, but it is now an API shim (or "façade") over the logging package. It is expected to wither away to nothing at some point. Why should you care? -------------------- This means that the environment variables EVENT_LOG_FILE, EVENT_LOG_SEVERITY, STUPID_LOG_FILE, STUPID_LOG_SEVERITY, and ZSYSLOG are no longer honored for Zope 2.8, ZODB, or ZEO. Zope 2 reads logging configuring from the zope.conf configuration file, and the test.py script for developers reads a log.ini file using the obnoxious configuration syntax provided by the logging package itself. If you use the ZODB distribution but not the rest of Zope, you probably want to start changing any of your code that uses zLOG to use the logging package. ZODB and ZEO will be changed to use the logging package directly as well to avoid dependence on the API shim. How can you help? ----------------- If you have some time to contribute to Zope development, the removal of zLOG calls from the ZODB and ZEO packages would be a welcome contribution. I've converted Signals/Signals.py and Zope/Startup/__init__.py, and some modules of ZODB and ZEO already use the logging package directly; these can serve as examples. -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation

8 16

I want to fix App.Management.Tabs.manage_workspace
by Chris Withers 21 Apr '04

21 Apr '04

Hi there, App.Management.Tabs.manage_workspace sucks as I've described in http://zope.org/Collectors/Zope/1286: 1. manage_workspace is only protected by the Authenticated role, and that is done directly, not even through a permission. 2. self.filtered_manage_roles then limits the options of what can be shown, which might end up being nothing. But, because the method is only protected by 'Authenticated', no chance is given to specify other user credentials (say, from a user folder higher up in the tree) which might be able to see something. 3. There's a bare try/except which masks errors. From what I can see, it should ONLY catch IndexError's. 4. The "raise TypeError" could do with some explanation. 5. The Unauthorized could raise a more helpful message "You are not authorized to view an of this object's management itnerface" What do people feel about the right way to solve this? 3,4 and 5 I'm comfortable with fixing, but I'm stumped as to what "the right thing" is to do on 1 and 2 which combine to create a thorny problem. The semantics I want are: "Show the 1st management tab the user is allowed to see, if they're not allowed to see anything, check if a user of the same name further up the userfolder tree can see anything" Is that right? If so, how do I go about implementing it? Finally, what branches should I do this on? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

4 3

order of transaction aborts
by zope＠netchan.cotse.net 21 Apr '04

21 Apr '04

Is there any way to influence the order of transaction aborts when you hijack the transaction mechanism in a similar way as Shared/DC/ZRDB/TM.py does? I have Folder and File like classes which make changes on the file system as a part of their operation. When within a transaction I make multiple changes to these objects and the transaction is aborted, I have to do some cleanup in reverse order as these operations were executed. AFAIK, the p_jar.abort() calls are made in the same order as the objects were registered in the transaction. Regards, Sandor

2 1

zope 2.7.0: no tracebacks produced
by Mika, David P (Research) 20 Apr '04

20 Apr '04

I am making a big upgrade and moving my products from 2.3.1 on HP-UX to 2.7.0 on windows 2000 and can't get zope to produce any tracebacks when it encounters errors. I've checked all the log files and monitor stdout to no avail. All I get is a brief html message with error type and value and instructions to check the error log. In the zope.conf file I have debug-mode on <eventlog> level ALL <logfile> path $INSTANCE/log/event.log level ALL </logfile> </eventlog> <logger trace> level ALL <logfile> path STDOUT </logfile> </logger> Any help here would be much appreciated!

2 1

Re: Proposal: Rename zope package
by Jim Fulton 20 Apr '04

20 Apr '04

Jim Fulton wrote: > Based on recent discussions, I've created a proposal: > > http://dev.zope.org/Zope3/RenameTheZopePackage > > to rename the "zope" package to "z". Unless there are strong > objections, we'll do this after we move the Zope repository head to > subversion at the end of the month. I've gotten enough negative feedback to "z", that I've added an alternative 4 to the proposal: 4. Rename the Zope package to Zope2 and provide a legacy Zope package - Rename the "Zope" package to "Zope2" - Put the Zope 3 "zope" package into the same location as "Zope2" in a combined installation. - Provide a legacy directory containing a "Zope" package. There will be an option to add this to the Python path. This option will be enabled by default in Zope 2.8 and disabled by default in Zope 2.9. Importing Zope will cause a deprecation warning. The legacy Zope package will have a README.txt file that explains what it is and refers people to the zope and Zope2 packages. This would mainly impact Zope 2. What do people think about alternative 4? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

8 8

Zope2.7.0rc2 AttributeError: 'NoneType' object has no
by Chris Bruce 20 Apr '04

20 Apr '04

Did this ever get resolved? I had similiar problem with a custom Product extending Folder. Noticed when I commented the following lines of code, the error went away: #security.setDefaultAccess("deny") #__roles__ = () ------------------------------------------------------ Thanks for the response Dieter, On 5 Feb 2004, at 18:51, Dieter Maurer wrote: > Tony McDonald wrote at 2004-2-5 12:43 +0000: >> ... >> We have an index_html (initially DTML document, then tried method) >> that >> can be created (located at /prototype/myporfolio/index_html), have >> it's >> security settings changed quite happily. Then when the object is >> called >> we get the error in the subject line. The system specs are; >> ... >> and the traceback is; >> >> Traceback (innermost last): >> ... >> Module Shared.DC.Scripts.Bindings, line 320, in >> __render_with_namespace__ >> Module Shared.DC.Scripts.Bindings, line 343, in _bindAndExec >> Module App.special_dtml, line 175, in _exec >> Module DocumentTemplate.DT_Util, line 201, in eval >> - __traceback_info__: RESPONSE >> Module <string>, line 0, in ? >> AttributeError: 'NoneType' object has no attribute 'setHeader' > > Looks like "RESPONSE" is "None". > > I do not see how this can happen... > Exactly! - this is why I said I'd never seen this before. It's a 2.6.1 Data.fs that's been dropped into a stock 2.7.0rc2 release and I get this error. I have no idea why this is happening, so I was hoping that it was an artifact of the 2.7.0rc2 release itself. > Probably, I would start debugging. > Quite likely, but I have *no* idea where to start with this. All the modules mentioned in the trackback are Zope supplied ones, not third party ones, so I'd assumed it might be the core software. > -- > Dieter once again, thanks for the reply Dieter. tone. -- Dr Tony McDonald, Asst Director, FMSC. 0191 245 4223 Project Manager, FDTL-4 ePortfolios http://www.eportfolios.ac.uk/

1 0

Proposal: Move to subversion for source code control of the Zope and ZODB projects
by Jim Fulton 20 Apr '04

20 Apr '04

I propose to move from CVS to subversion for the Zope and ZODB projects; http://dev.zope.org/Zope3/MovingSCMToSubversion Initially, I propose to move just the repository heads. Maintenamce branches (e.g. Zope 2.6 and Zope 2.7) will remain in CVS. Comments are welcome here, and in the Wiki. I propose to make this a topic of discussion at the upcoming Zope commnity IRC chat: http://mail.zope.org/pipermail/zope-announce/2004-April/001409.html Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

7 9