[Zope-dev] Re: [Zope3-dev] Proposal: Move to subversion for source code control of the Zope and ZODB projects
From: Jim Fulton [EMAIL PROTECTED] Initially, I propose to move just the repository heads. Maintenamce branches (e.g. Zope 2.6 and Zope 2.7) will remain in CVS. What is the rationale behind not moving it all? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZODB-Dev] Re: [Zope3-dev] Proposal: Move to subversion for source code control of the Zope and ZODB projects
--On Montag, 12. April 2004 13:07 Uhr +0200 Lennart Regebro [EMAIL PROTECTED] wrote: From: Jim Fulton [EMAIL PROTECTED] Initially, I propose to move just the repository heads. Maintenamce branches (e.g. Zope 2.6 and Zope 2.7) will remain in CVS. What is the rationale behind not moving it all? I won't be forced to migrate all my existing scripts to use SVN at this time. Using SVN for Zope 2.8+ is ok and a good start to learn using SVN. -aj ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [patch] More secure cookie crumbler?
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 ttime():
+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
+
[Zope-dev] Re: [patch] More secure cookie crumbler?
On Mon, 12 Apr 2004, Chris Withers wrote: I think the attached patch (against CookieCrumbler 1.1) makes CookieCrumbler a little more secure. Your patch won't work with multiple ZEO app servers. It appears to store the tokens in a module global. Do not apply it. PS: To make cookie auth properly secure, you really need to be working over SSL only I agree--SSL is required. Let's not give people a false sense of security by changing CookieCrumbler. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [patch] More secure cookie crumbler?
Chris Withers wrote: 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 ;-) The problem of using cookies for auth creds is a little more complex than that. The reality is, in a well written application, cookies should never be used to store auth creds, even if you only send them over SSL. The reason is that client side scripting languanges are usually permitted access to cookie structures whereas they are explicitly forbidden access to auth cred structures. This is one of the main things that makes cross-site scripting attacks dangerous. ...and given that Zope is already highly susceptible to cross-site scripting attacks... Of course you can limit the potential for serious damage with aggressive expiration, source address restrictions, etc. but few people will go through the trouble, and I'd wager most people using the various cookie-based auth folder products don't even know the risks. -- Jamie Heilman http://audible.transient.net/~jamie/ I was in love once -- a Sinclair ZX-81. People said, No, Holly, she's not for you. She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway. -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [ZODB-Dev] Re: [Zope3-dev] Proposal: Move to subversion for source code control of the Zope and ZODB projects
On Mon, Apr 12, 2004 at 08:11:44AM -0400, Tres Seaver wrote: | Lennart Regebro wrote: | From: Jim Fulton [EMAIL PROTECTED] | | Initially, I propose to move just the repository heads. Maintenamce | branches (e.g. Zope 2.6 and Zope 2.7) will remain in CVS. | | What is the rationale behind not moving it all? | | Risk mitigation; we have significant support requirements for deployed | systems built around CVS for both 2.6- and 2.7-based sites, whereas the | head and Zope3 have no such inertia. We don't know enough about the | migration process to have any confidence that existing history / | branches, etc., won't be somehow messed up, which makes it prudent to | plan the migration around the already-unstable bits. Just FYI, Kapil has been doing a good job at improving the script that migrates from CVS to SVN, and we are ready to flip the switch to move Plone, Collective and possibly Archetypes to SVN. -- Sidnei da Silva [EMAIL PROTECTED] http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher Real computer scientists like having a computer on their desk, else how could they read their mail? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [patch] More secure cookie crumbler?
Shane Hathaway wrote: I think the attached patch (against CookieCrumbler 1.1) makes CookieCrumbler a little more secure. Your patch won't work with multiple ZEO app servers. It appears to store the tokens in a module global. Do not apply it. Well, that's a little harsh. The default methods will only work on setups where there's at most one ZEO client accepting web requests for each user. However, all you have to do is drop 3 ZSQL-methods-filtereted-through-python-scripts or python-scripts-using-a-session-data-container and it works across any number of ZEO clients accepting web requests for any user. PS: To make cookie auth properly secure, you really need to be working over SSL only I agree--SSL is required. Let's not give people a false sense of security by changing CookieCrumbler. That was the reason for the long NB/PS at the end of the email. The patch does still prevent the Browser seeing the password of the user, and reduces the chances of session hijacking. With normal cookie crumbler, if you snoop a session, you can keep using it until the user changes their password. With the patch, at longest it'll be until the app server is restarted, but more likely the 20 minute session expirey time on the server and, if the session was being using actively at the time it was snooped, until the user next requests a page. For me, that's worth patching for, it's up to you if you want to include it in an offical CookieCrumbler release or not ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [patch] More secure cookie crumbler?
Jamie Heilman wrote: The problem of using cookies for auth creds is a little more complex than that. The reality is, in a well written application, cookies should never be used to store auth creds, even if you only send them over SSL. The patch means that auth creds are never sent, only an auth token that's valid for 20 mins or so, or you could set it to less. The reason is that client side scripting languanges are usually permitted access to cookie structures whereas they are explicitly forbidden access to auth cred structures. This is one of the main things that makes cross-site scripting attacks dangerous. Can you explain the XSS risk when a client user is not permitted to write HTML content to be stored by the app? restrictions, etc. but few people will go through the trouble, and I'd wager most people using the various cookie-based auth folder products don't even know the risks. This I'd agree with, but I find the argument this car's breaks only let me stop in 1 mile, so there's no point in changing them so I can stop in 0.5 miles a poor one... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [patch] More secure cookie crumbler?
On Mon, 12 Apr 2004, Chris Withers wrote: For me, that's worth patching for, it's up to you if you want to include it in an offical CookieCrumbler release or not ;-) Making cookie authentication secure is surprisingly difficult, and you've barely taken one step. I don't want CookieCrumbler to go in this direction at all. A much more fruitful endeavor would be to simply add digest authentication support to Zope's user folders. See the middle of this page for a fairly clear explanation: http://frontier.userland.com/stories/storyReader$2159 Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: circular referenced persistent objects
On Sat, 10 Apr 2004 14:11:56 -0500 [EMAIL PROTECTED] wrote: I have the following setup (unrelated lines are omitted): class Deliverer(Folder): def manage_afterAdd(self, item, container): if item is self: self.__ac_local_roles__ = dr_localroles(self) class dr_localroles(Persistent): def __init__(self, dr): self.dr = dr dr_localroles implements a few methods of the dictionary interface, so I can always check the effective settings via the Security/local roles zmi page. In order to computing roles, dr_localroles requires its parent object instance (Deliverer), that's why I store a reference to it as an attribute. Question: - Is there a way for dr_localroles to refer its parent without holding a reference to it or using weak reference? Yes, use acquisition. Make dr_localroles inherit from Acquisition.Implicit or Acquisition.Explicit. - Is there an equivalent of sys.getrefcount for ZODB persistent objects? Cycles like this will not be a problem for ZODB. When either object is deleted it will no longer be reachable from the root, regardless of cycles between them. When the database is packed, unreachable objects are removed. Also a note for the archives: I wanted to make sure that if I delete a Deliverer object, it will indeed be removed from ZODB. Once you pack, yes. For this I got the oid of the object, deleted it and than tried to get it back via the oid. The trick is, that you'll only get a POSKeyError if you pack the database and flush the cache. This latter one was not obvious for me. Such tricks are not necessary and cause your app to rely too much on the curent implementation of ZODB. Just let the database take care of this for you. In any case, there is a (new) persistent weakref class in ZODB 3.3 which allows you to weakly refer to other persistent objects without causing them to stay in the database like normal references do. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] Proposal: Move to subversion for source code control of the Zope and ZODB projects
Jamie Heilman wrote: Jim Fulton wrote: I propose to move from CVS to subversion for the Zope and ZODB projects; http://dev.zope.org/Zope3/MovingSCMToSubversion No complaints from me. I do wonder though... one thing I've noticed about ZC's CVS usage in the past is that you folks never export your code for releases. Indeed, the 2.7.0 source release wasn't even checked out with -P so there's a lot of goofy-looking empty directories in the tarball. I'm sure that was an oversight. Thanks for pointing it out. Of course, with subversion, we won't have those stupid directories in the first place. A common idiom through a great deal of the code is: __version__='$Revision: 1.201 $'[11:-2] Now... thats a cute hack, but its also a silly waste of time. Not enough to mean anything. BTW, we're moving away from using this idiom, since Python __version__ variables are not widely used and aren't really intended to track individial file revisions AFAICT. If releases were exported with -kv, it wouldn't be necessary. That would break Id variables. We do use $Id$ and I want the full ID string so that the ident command will work. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Re: circular referenced persistent objects
Casey, Thanks for the clarification. - Is there an equivalent of sys.getrefcount for ZODB persistent objects? This is still a question. Is there any way, to determine how many times a zodb persistent object is referenced? sys.getrefcount seems to tell me only those references which are currently loaded in the memory. Also another very interesting question is that who referring to a specific object. For this I got the oid of the object, deleted it and than tried to get it back via the oid. The trick is, that you'll only get a POSKeyError if you pack the database and flush the cache. This latter one was not obvious for me. Such tricks are not necessary and cause your app to rely too much on the curent implementation of ZODB. Just let the database take care of this for you. I used this trick only for exploring ZODB behavior. The application doesn't do any nasty tricks. Regards, Sandor ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: circular referenced persistent objects
On Mon, 12 Apr 2004 10:57:43 -0500 [EMAIL PROTECTED] wrote: Casey, Thanks for the clarification. - Is there an equivalent of sys.getrefcount for ZODB persistent objects? This is still a question. Is there any way, to determine how many times a zodb persistent object is referenced? sys.getrefcount seems to tell me only those references which are currently loaded in the memory. Also another very interesting question is that who referring to a specific object. Not from a given object. You would need to walk the forward references (which are tracked) of all the objects to find this out. I posted some code to do this from any starting object in the ZODB a long time ago. Search the mail archives if you're interested. For this I got the oid of the object, deleted it and than tried to get it back via the oid. The trick is, that you'll only get a POSKeyError if you pack the database and flush the cache. This latter one was not obvious for me. Such tricks are not necessary and cause your app to rely too much on the curent implementation of ZODB. Just let the database take care of this for you. I used this trick only for exploring ZODB behavior. The application doesn't do any nasty tricks. ok. -Casey ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Re: circular referenced persistent objects
[Sandor] This is still a question. Is there any way, to determine how many times a zodb persistent object is referenced? ZODB itself doesn't keep track of that, although it's possible to write a storage that does. FileStorage does not. BerkeleyStorage did (past tense because Zope Corp has given up on BerkeleyStorage for now). sys.getrefcount seems to tell me only those references which are currently loaded in the memory. Yes, sys.getrefcount() is a Python builtin, and only knows about in-memory Python objects. Python (and its builtins) doesn't know anything about persistence. Also another very interesting question is that who referring to a specific object. Like at the start, it would be possible to write a storage that saves away that kind of inverted index, but I don't know of any that do. Given a particular flavor of storage, and detailed knowledge of its implementation, you can write scripts to crawl over the storage and compute anything you like. For FileStorage, the standard tools fsrefs.py and fsdump.py illustrate two ways of picking apart an .fs file. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZConfig 2.1 released
I've posted a distribution for ZConfig 2.1 on the ZConfig page: http://zope.org/Members/fdrake/zconfig/ This fixes a few bugs and improves the ability to set default values in schemas. It also adds some helpful schema building blocks, including a general mapping type and support for Python's logging package. This version of ZConfig requires Python 2.3. From the news file: - Removed compatibility with Python 2.1 and 2.2. - The default objects use for section values now provide a method getSectionAttributes(); this returns a list of all the attributes of the section object which store configuration-defined data (including information derived from the schema). - Default information can now be included in a schema for key name=+ and multikey name=+ by using default key= - More documentation has been added to discuss schema extension. - Support for a Unicode-free Python has been fixed. - Derived section types now inherit the datatype of the base type if no datatype is identified explicitly. - Derived section types can now override the keytype instead of always inheriting from their base type. - import package='...'/ makes use of the current prefix if the package name begins witha dot. - Added two standard datatypes: dotted-name and dotted-suffix. - Added two standard schema components: ZConfig.components.basic and ZConfig.components.logger. -Fred -- Fred L. Drake, Jr. fred at zope.com PythonLabs at Zope Corporation ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] start_new_thread / user issue
Hi, Within a python file I do a call to thread.start_new_thread(...). Before this call, I am the admin user (verified by calling AccessControl.getSecurityManager().getuser().getUserName()). After the call, however, in the new thread, the user is now Anonymous User. Is there any way to somehow pass the user between threads because the code executed in the new thread needs the same permissions as the code executed in the old thread? I can obviously pass the user name to the new thread, but I'm not sure if that does me any good, because I doubt an Anonymous User would have permission to make itself another user. Any hints or suggestions would be appreciated. Thanks, --Toby. --- Toby Gustafson Senior Software Engineer Tyrell Software Corporation Email: [EMAIL PROTECTED] --- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)
G'Day, Well, step one is done ... I now have Zope + Ape using Subversion as it's filesystem !! This is step one because, as Shawn suggested (Thanks for the pointer, that's what I needed!), this simply means that Zope uses SVN purely as a filesystem. Because of subversion's nature, I want to look at 2 things beyond this that traditional filesystems don't support: - Use zope's username for SVN logging. - History/Undo support: View past revisions of an object, and revert to such a past revision. - Zope Version support: SVN is fully transactional and atomic, this should allow for support of Zope versions (I think ?) In the longer term, there's great opportunity for: - Built-in conflict management and resolution: No more need for a SafetyBelt type approach. Right now I haven't looked at this at all. I plan to implement smart merging where possible (It might work already actually, I just need to test it). True conflicts (Where a merge can't be accomplished withouth user interaction) would raise some sort of conflict error. - Editing Zope content objects through interaction with the svn repository. I can checkout the repository, edit some objects, and chek them back in, never interacting with Zope directly ... I've already tried this ! Works great for text based content types such as PageTemplates or DTML Documents and so on ... I even did it with a JPG, though because the properties hold width and height, you get some weird looking pictures :) The concept is valid though. There may someday be a way to leverage this functionality better with a purpose built client of some sort. - Leveraging SVN's property management. Content in SVN has properties, much like Zope does. I haven't looked at it yet, but I've noticed .properties file appearing ... I'm guessing those are the Zope properties, which would be better handled by subversion's property mechanism. And properties are versioned too ! In the realm of the wishful thinking, there's even more: Right now, HEAD (Latest/youngest revision) is always used and worked with. The really powerful feature I want to eventually get to is publsihing something of a given revision, while editing another. One potential paradigm for distiguishing between the two modes of operation could be to use anonymous vs. authenticated. This is not useful to everyone, but can be in certain circumstances, most notably where authenticated = authors/developpers and anonymous = normal users. This however requires ZMI interfaces, and in my case CMF ones as well ... This would be global though ... Eventually it'd be nice to have per object control of this stuff. Andy McKay says it can't be done, anybody care to contradict him ? :P I image I'd have to monkey pathc something DEEP in the Zope code base, but I find the mix-in class that's the commonn denominator ... why not ? Right now I've been working within the fs module of apelib. I'm going to split it off into a seperate one so that it's a clean merge with Ape's code base, in case someone wants to try it, or it eventually makes into Ape's default distribution ?? ;) Anyways, I'm just rambling by now ... Comments, thoughts and constructive criticism welcome ! Thanks, J.F. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Shane Hathaway Sent: April 8, 2004 11:20 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Zope-dev] Using a truely revision based storage for Zope ? [EMAIL PROTECTED] wrote: I've started looking at the ZODB and APE packages to try and get some understanding of how the whole storage interaction works, but it'll take me some time to figure it all out ... So I thought I'd get feedback on the idea first ... Sounds great! If I were you, I would start by replacing Ape/lib/apelib/fs/fileops.py with something that uses the Subversion module. It's a very simple module and you should be able to get pretty far that way. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [patch] More secure cookie crumbler?
Chris Withers wrote: The patch means that auth creds are never sent, only an auth token that's valid for 20 mins or so, or you could set it to less. The token *is* the cred in that scenario, you can't not send some form credentials. Can you explain the XSS risk when a client user is not permitted to write HTML content to be stored by the app? The malicious code doesn't have to be stored in the app being attacked. Typically its part of a URI pointing to the app to attack and includes the xss payload. That URI however could be found any number of places... social engineering usually comes into play then to get the victim to click on it. While its typically easier to convince users to click a link if it comes from the same site it appears to be going to, (think about message board systems like slash where where hyperlinks in comments are usually suffixed by [domain.com] to give the user the ability to avoid goatse and such) in the end, what dictates the likelyhood of attack is the value of the service more than anything. [Sadly this doesn't dictate the likely hood of XSS holes getting reported on security lists, where people frequently post every about silly little backwater application they can find.] restrictions, etc. but few people will go through the trouble, and I'd wager most people using the various cookie-based auth folder products don't even know the risks. This I'd agree with, but I find the argument this car's breaks only let me stop in 1 mile, so there's no point in changing them so I can stop in 0.5 miles a poor one... Well, knock yourself out, I mean, clearly auth techniques based around cookies need a lot of additional protection. Those same protections, if written modularly, can usually be used to bolster HTTP auth as well, so there's no harm in writing them. Its convincing people to actually use the damned things thats the problem. -- Jamie Heilman http://audible.transient.net/~jamie/ I was in love once -- a Sinclair ZX-81. People said, No, Holly, she's not for you. She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway. -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Proposal: Move to subversion for source code control of the Zope and ZODB projects
fwiw, i've been able to get good results at migrating the plone repository and branches using the refinecvs migration script http://lev.serebryakov.spb.ru/refinecvs/ the cvs2svn script included with subversion had several issues with branches, although it was a few months ago (prior to svn 1.0) that i last attempted to use it. with a little luck plone will be on svn before the end of the month. i've also setup some one way cvs-svn sync scripts for mirroring zope.org cvs into an svn repository to allow for automated pull of dependencies via svn:externals. -kapil On Mon, 2004-04-12 at 08:44, Sidnei da Silva wrote: On Mon, Apr 12, 2004 at 08:11:44AM -0400, Tres Seaver wrote: | Lennart Regebro wrote: | From: Jim Fulton [EMAIL PROTECTED] | | Initially, I propose to move just the repository heads. Maintenamce | branches (e.g. Zope 2.6 and Zope 2.7) will remain in CVS. | | What is the rationale behind not moving it all? | | Risk mitigation; we have significant support requirements for deployed | systems built around CVS for both 2.6- and 2.7-based sites, whereas the | head and Zope3 have no such inertia. We don't know enough about the | migration process to have any confidence that existing history / | branches, etc., won't be somehow messed up, which makes it prudent to | plan the migration around the already-unstable bits. Just FYI, Kapil has been doing a good job at improving the script that migrates from CVS to SVN, and we are ready to flip the switch to move Plone, Collective and possibly Archetypes to SVN. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
On 12/04/2004, at 10:39 PM, Shane Hathaway wrote: On Mon, 12 Apr 2004, Chris Withers wrote: I think the attached patch (against CookieCrumbler 1.1) makes CookieCrumbler a little more secure. Your patch won't work with multiple ZEO app servers. It appears to store the tokens in a module global. Do not apply it. I've attached some similar code we are using. Instead of patching CookieCrumbler, it extends it and is drop-in compatible. We are stuffing the auth credentials into the SESSION, so it will work with ZEO if your SESSION machinery copes (either using server affinity or your session storage is mounted by the ZEO clients from a central storage). I was going to pack this up and release it as a product under BSD or MIT licence, but I either forgot or came up with a technical reason not to. Either way, I'm having memory issues :-) SessionCookieCrumbler.py Description: Binary data Does this look worth releasing as a separate product? PS: To make cookie auth properly secure, you really need to be working over SSL only I agree--SSL is required. Let's not give people a false sense of security by changing CookieCrumbler. Unfortunately it causes performance to blow. We compromise by having the auth form on the SSL server, but the rest of the application on raw HTTP. This at least reduces the window that a replay attack can be used. It would be possible to tie the auth credential down to a particular IP address, but that is entering the world of diminishing returns and incompatibilities (think ISP's with farms of proxies - is this still a problem nowadays?). -- Stuart Bishop [EMAIL PROTECTED] http://www.stuartbishop.net/ PGP.sig Description: This is a digitally signed message part ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: Zope + Ape + Subversion (was: RE: [Zope-dev] Using a truely revis ion based storage for Zope ?)
On Mon, 12 Apr 2004 [EMAIL PROTECTED] wrote: Well, step one is done ... I now have Zope + Ape using Subversion as it's filesystem !! That's fantastic! I'll write a more detailed reply soon. :-) Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [patch] More secure cookie crumbler?
On 04/12/04 09:04, Chris Withers wrote: For me, that's worth patching for, it's up to you if you want to include it in an offical CookieCrumbler release or not ;-) BTW, I wouldn't mind if you or Stuart took over maintainership of CookieCrumbler after the next release. Then you'd be able to take it any direction you want. I don't believe its model can support well the things you're asking it to do, but I'll happily give you the chance to prove me wrong. :-) Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [patch] More secure cookie crumbler?
Stuart Bishop wrote: On 12/04/2004, at 10:39 PM, Shane Hathaway wrote: On Mon, 12 Apr 2004, Chris Withers wrote: I think the attached patch (against CookieCrumbler 1.1) makes CookieCrumbler a little more secure. Your patch won't work with multiple ZEO app servers. It appears to store the tokens in a module global. Do not apply it. I've attached some similar code we are using. Instead of patching CookieCrumbler, it extends it and is drop-in compatible. We are stuffing the auth credentials into the SESSION, so it will work with ZEO if your SESSION machinery copes (either using server affinity or your session storage is mounted by the ZEO clients from a central storage). I was going to pack this up and release it as a product under BSD or MIT licence, but I either forgot or came up with a technical reason not to. Either way, I'm having memory issues :-) Does this look worth releasing as a separate product? I haven't looked at the code. Do you have actual experience using core sessions over ZEO? I pondered that recently for a client, and fell back to using a hacked together version of Anthony Baxter's SQLSession product, instead. SessionStorage would work either as a separate product, or as a knob for the CookieCrumbler, I think. If ZPL is an adequate license, why don't you check it in there? PS: To make cookie auth properly secure, you really need to be working over SSL only I agree--SSL is required. Let's not give people a false sense of security by changing CookieCrumbler. Unfortunately it causes performance to blow. We compromise by having the auth form on the SSL server, but the rest of the application on raw HTTP. This at least reduces the window that a replay attack can be used. It would be possible to tie the auth credential down to a particular IP address, but that is entering the world of diminishing returns and incompatibilities (think ISP's with farms of proxies - is this still a problem nowadays?). Yes; not only that, but AOL users change their IPs seemingly at random during a single session. Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [patch] More secure cookie crumbler?
Jamie Heilman wrote: Chris Withers wrote: The patch means that auth creds are never sent, only an auth token that's valid for 20 mins or so, or you could set it to less. The token *is* the cred in that scenario, you can't not send some form credentials. Can you explain the XSS risk when a client user is not permitted to write HTML content to be stored by the app? The malicious code doesn't have to be stored in the app being attacked. Typically its part of a URI pointing to the app to attack and includes the xss payload. That URI however could be found any number of places... social engineering usually comes into play then to get the victim to click on it. While its typically easier to convince users to click a link if it comes from the same site it appears to be going to, (think about message board systems like slash where where hyperlinks in comments are usually suffixed by [domain.com] to give the user the ability to avoid goatse and such) in the end, what dictates the likelyhood of attack is the value of the service more than anything. [Sadly this doesn't dictate the likely hood of XSS holes getting reported on security lists, where people frequently post every about silly little backwater application they can find.] Yup. I worry hard about XSS when it comes to my banking, my credit cards, my taxes; I don't much care when it comes to a news site. restrictions, etc. but few people will go through the trouble, and I'd wager most people using the various cookie-based auth folder products don't even know the risks. This I'd agree with, but I find the argument this car's breaks only let me stop in 1 mile, so there's no point in changing them so I can stop in 0.5 miles a poor one... Well, knock yourself out, I mean, clearly auth techniques based around cookies need a lot of additional protection. Those same protections, if written modularly, can usually be used to bolster HTTP auth as well, so there's no harm in writing them. Its convincing people to actually use the damned things thats the problem. Right, mostly for the same reasons you point out above: the perceived threat isn't enough to warrant the pain. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: start_new_thread / user issue
Toby Gustafson wrote: Hi, Within a python file I do a call to thread.start_new_thread(...). Before this call, I am the admin user (verified by calling AccessControl.getSecurityManager().getuser().getUserName()). After the call, however, in the new thread, the user is now Anonymous User. Is there any way to somehow pass the user between threads because the code executed in the new thread needs the same permissions as the code executed in the old thread? I can obviously pass the user name to the new thread, but I'm not sure if that does me any good, because I doubt an Anonymous User would have permission to make itself another user. Any hints or suggestions would be appreciated. Given that you trust yourself ;), you can add a security context from within the second thread; you could pass the user ID to the thread via one of several forms of currying, e.g. via instance variables:: class TrustedSecurityTask: def __init__(self, user_id): self._user_id = user_id def __call__(self, *args, **kw): sm = getSecurityManager() sm.newSecurityContext(None, User(self._user_id)) # your code here . thread = Thread(TrustedSecurityTask(user_id)) thread.start() Tres. -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
