Zope-Dev February 2003

zope-dev@zope.dev

81 participants
91 discussions

LOTS of roles?
by Paul Winkler 11 Mar '03

11 Mar '03

has anybody ever set up a site with a large number of roles? we're contemplating a security model for our app that might lead to ~ 100 Roles within a year, possibly thousands within the next 5 years. (Outline of the actual problem is at the end of this message) (The users and roles will be managed in LDAP, by the way; we plan to use LDAPUserFolder for this and not do any user or role administration in Zope.) I seem to recall the Zope Book or some other text advising against large numbers of roles, but IIRC that was only because of the UI. Obviously the ZMI default Security tab will not scale. I think I can replace that without too much trouble: possibly have the main page list only the roles vertically, with each one being a link to manage_roleForm as it is currently. As the number of roles grows very large this main page could be broken into batches if necessary. And of course there'd be a link to another page with a list of permissions to manage, and each of those would link to manage_permissionForm. i'm also thinking to use checkboxes as the current UI is too easy to unselect everything by accident. The question is, if I can solve the interface issues, are there other reasons not to have hundreds or thousands of roles? It seems to me that there should not be performance issues, since I assume that finding the current user's roles is just a dictionary lookup which should scale pretty well... we're not talking millions of roles here, and each user will have only a handful of roles. comments? more about our scenario: * We must anticipate users at hundreds of locations * there might be 10 or so users at each location * permissions can be grouped pretty well into tasks, but are specific to a location - permission to do a task at one location must not mean permission at all locations. To me this suggests several Roles per location, corresponding to the grouped tasks at that location. * each user might work from several different locations * each user might need different permissions when working at different locations * We have multiple applications, not all in zope, so LDAP is looking attractive. -- Paul Winkler http://www.slinkp.com

8 22

How to trigger Zope externally (mail)
by Ross Boylan 10 Mar '03

10 Mar '03

I am working on a poll/survey type product and want to handle responses by email as well as the web. If you have any advice about the best architecture, I would appreciate it. I'm currently using Zope 2.5 on Linux, though it would be nice if the solution weren't too platform dependent. Here are some options I have thought of. 1. Incoming mail goes to a pipe, which is a program that processes the message. I think the main drawback of this approach is that I would need to run Zope on top of ZEO so that multiple processes could access the database safely. I'm also not sure how hard it would be to reestablish the context of my product outside of regular Zope. Aside from these concerns, this seems the most natural approach. 2. Incoming mail goes to mbox; via the regular zope web interface I periodically point to the mbox and request that it be processed. Ugly, but relatively simple. Some locking and concurrency issues. Likely to result in much slower response to mail. Also, there could be some problems distinguishing message boundaries; in practice, probably not a problem. 3. Incoming mail goes to temp file or temp named pipe*. The running zope is tickled via http: with the name of the file/pipe, and processes it from there. *By "temp named pipe" I mean each mail would need a unique pipe name. I think if I try to use a single named pipe I may have trouble if multiple emails go down it around the same time. 4. Deliver the email to the running zope via some other protocol, e.g., ftp. I'm not sure how to set this up. ------------------------------ I welcome comments on these approaches, or others that are even better! Also, I would like the approach to be reasonably secure. Thanks.

7 8

Trying to understand the nuances of a VerboseSecurity report ..
by Jean Jordaan 04 Mar '03

04 Mar '03

Hi all (and Shane in particular :) I'm triggering this error: Unauthorized: The owner of the executing script is defined outside the context of the object being accessed. Access to 'basic' of (License_PropertySheetsClass instance at e204528) denied. Access requires Access_contents_information_Permission, granted to the following roles: ['Administrator', 'Manager', 'Owner', 'Supporter']. The executing script is (PythonScript instance at e208eb8), owned by jean. I can't understand why .. there is exactly one acl_users in this Zope instance, in the root, where user 'jean' is defined. The whole application normally works fine. Currently, the error is being triggered by a ZUnit unit test. All the other unit tests (adding, editing and deleting instances of various kinds) works fine. The code where the error is occuring is this: """ # Create a new License instance and grab its propertysheet license_id = context.ObjectCounters.newID('License') new_license = container.newItem(license_id) new_license_propertysheet = new_license.propertysheets.basic """ All I can think is that that object 'basic' lacks context for some reason (i.e. lacks an acquisition wrapper?). I can't think why it lacks context .. we use that idiom all over the app, and don't normally get any problems. I'm trying to see if reading VerboseSecurity's source will help, but all I've found so far is a suspect double negation: """ def userHasRolesButNotInContext(user, object, object_roles): '''Returns 1 if the user has any of the listed roles but is not defined in a context which is not an ancestor of object. ''' """ Surely either one of those 'not's should go? -- Jean Jordaan http://www.upfrontsystems.co.za

3 6

ZPublisher XMLRPC extension for user exceptions (II)
by Illarramendi Amilibia, Aitor 28 Feb '03

28 Feb '03

Hello everybody: I hope I've send it in the proper format this time :) I apologize for the first post I made, that was the corporative mail tool that automated all the e-mail... I'm making some kind of development related to invoke externally from a Java Applet some ZOPE product methods via XML-RPC. I use ZOPE as the XMLRPC server, as it can 'listen' for XMLRPC requests, find the method requested using URL and traversal, invoke the method and receive the return value of it and then encapsulate the result in a XMLRPC response. Anyways, I want to report some exceptions from my ZOPE product python methods through XML-RPC to the applet. As my methods don't work directly with XMLRPC, all is embedded inside ZOPE, all the XMLRPC works are transparent for my python methods, so I didn't realize how I could do it. After looking for the ZOPE code responsible of the XMLRPC request process and XMLRPC response generation I found that some of the work was being done in ZPublisher xmlrpc.py code (Response stuff). Then when I started to read the comments of the code I found this in the Response class of the code: """ It's probably possible to improve the 'exception' method quite a bit. The current implementation, however, should suffice for now. """ But as you will see is not enough, at least for my needs. I want to define my own exceptions in my product, this exceptions could be defined as follows: class MyOwnException: __init__(self, faultCode, faultString): self.faultCode = faultCode self.faultString = faultString Obviously I want to map XMLRPC-like fault format. Then, I could raise this exception from my method, and I will want that the class responsible of making the XMLRPC Response for my XMLRPC client will use it for composing the XML for XMLRPC using my fault code and fault string. But I found that xmlrpc.py doesn't take into account that (i'm talking of ZOPE 2.6.0) so i had to make some changes in the code of ZPublisher/xmlrpc.py: def exception(self, fatal=0, info=None, absuri_match=None, tag_search=None): # Fetch our exception info. t is type, v is value and tb is the # traceback object. if type(info) is type(()) and len(info)==3: t,v,tb = info else: t,v,tb = sys.exc_info() # Don't mask 404 respnses, as some XML-RPC libraries rely on the HTTP # mechanisms for detecting when authentication is required. Fixes Zope # Collector issue 525. if t == 'Unauthorized' or (isinstance(t, types.ClassType) and issubclass(t, Unauthorized)): return self._real.exception(fatal=fatal, info=info) # Create an appropriate Fault object. Containing error information Fault=xmlrpclib.Fault f=None try: # Strip HTML tags from the error value v = str(v) remove = [r"<[^<>]*>", r"&[A-Za-z]+;"] for pat in remove: v = re.sub(pat, " ", v) from Globals import DevelopmentMode if DevelopmentMode: from traceback import format_exception value = '\n' + ''.join(format_exception(t, v, tb)) else: value = '%s - %s' % (t, v) ###### my own extension for catching user exceptions START ##### try: faultCode = getattr(sys.exc_info()[1],'faultCode') faultString = getattr(sys.exc_info()[1],'faultString') except: print "no according exception type" ###### my own extension for catching user exceptions FINISH ##### if isinstance(v, Fault): f=v ###### my own extension for catching user exceptions START ##### elif (faultCode and faultString) : f = xmlrpclib.Fault(faultCode,faultString) ###### my own extension for catching user exceptions FINISH ###### elif isinstance(v, Exception): f=Fault(-1, 'Unexpected Zope exception: %s' % value) else: f=Fault(-2, 'Unexpected Zope error value: %s' % value) except: f=Fault(-3, "Unknown Zope fault type") # Do the damage. self.setBody(f) self._real.setStatus(200) return tb By that way, I could send my own fault code and fault descriptions via XML-RPC. But as you can see, I have to extend ZOPE code, and I don't want to do it, I have to work with standard releases of ZOPE. Do you think that something like that would be improved in an early future for next ZOPE releases? Any opinion will be really appreciated. Thanks for advance. Regards. Aitor Illarramendi Amilibia Ingeniero de software Mando y Control Carretera de Loeches, 9 28850 - Torrejón de Ardoz, Madrid (ESPAÑA) Tel: +34-91-626.80.60 Fax: +34-91-626.81.14 aillarramendi(a)indra.es www.indra.es

3 2

Index errors revisited: KeywordIndex unindex_object could not remove documentId -883140122 from index ComponentVersions. This should not happen.
by Jean Jordaan 28 Feb '03

28 Feb '03

Hi all We've posted about this before, but never managed to pin down the issue nicely. It doesn't interfere with our application, as far as we could tell, so we've let it slide. Here's another attempt at formulating the problem. We run a script which iterates over 719 <ZClass License> instances. For each instance, either one or two <ZClass Reminder> instances are created and edited. The script completes, logging all the way: 2003-02-27T09:43:44 INFO(0) MyDebugLog recreate_reminders> INFO: creating reminders for License_99 Then, Zope starts spitting out 657 errors like the following: 2003-02-27T09:43:49 ERROR(200) KeywordIndex unindex_object could not remove documentId -883140119 from index ComponentVersions. This should not happen. Traceback (innermost last): File /usr/local/zope/2-5-1/lib/python/Products/PluginIndexes/common/UnIndex.py, line 168, in removeForwardIndexEntry (Object: ComponentVersions) KeyError: -883140119 Most of these errors are identical. There are 172 unique errors, the rest are all retries. The 172 keys are not in the catalog. The only indexes involved are ComponentVersions and NodeNames, both 'lines' properties of <ZClass Reminder>. Does anyone know how to cause this, so that I can stop doing it? I'm trying to narrow it down again .. (Zope 2.5.1 (source release, python 2.1, linux2), python 2.1.3, linux2) -- Jean Jordaan http://www.upfrontsystems.co.za

4 5

RE: [Zope-dev] ZPublisher XMLRPC extension for user exceptions
by Illarramendi Amilibia, Aitor 28 Feb '03

28 Feb '03

Ok. I'm sorry, I'll send it again in the proper format. Regards. -----Mensaje original----- De: Dieter Maurer [mailto:dieter@handshake.de] Enviado el: jueves 27 de febrero de 2003 20:20 Para: Illarramendi Amilibia, Aitor Asunto: Re: [Zope-dev] ZPublisher XMLRPC extension for user exceptions You should not post HTML message to this mailing list. You should not attach images to mails send to technical mailing lists. Large posts (yours is larger than 30 kB) are rarely read. I discarded your message without any attempt to read it... Dieter

1 0

ZPublisher XMLRPC extension for user exceptions
by Illarramendi Amilibia, Aitor 27 Feb '03

27 Feb '03

Hello everybody: I'm making some kind of development related to invoke externally from a Java Applet some ZOPE product methods via XML-RPC. I use ZOPE as the XMLRPC server, as it can 'listen' for XMLRPC requests, find the method requested using URL and traversal, invoke the method and receive the return value of it and then encapsulate the result in a XMLRPC response. Anyways, I want to report some exceptions from my ZOPE product python methods through XML-RPC to the applet. As my methods don't work directly with XMLRPC, all is embedded inside ZOPE, all the XMLRPC works are transparent for my python methods, so I didn't realize how I could do it. After looking for the ZOPE code responsible of the XMLRPC request process and XMLRPC response generation I found that some of the work was being done in ZPublisher xmlrpc.py code (Response stuff). Then when I started to read the comments of the code I found this in the Response class of the code: """ It's probably possible to improve the 'exception' method quite a bit. The current implementation, however, should suffice for now. """ But as you will see is not enough, at least for my needs. I want to define my own exceptions in my product, this exceptions could be defined as follows: class MyOwnException: __init__(self, faultCode, faultString): self.faultCode = faultCode self.faultString = faultString Obviously I want to map XMLRPC-like fault format. Then, I could raise this exception from my method, and I will want that the class responsible of making the XMLRPC Response for my XMLRPC client will use it for composing the XML for XMLRPC using my fault code and fault string. But I found that xmlrpc.py doesn't take into account that (i'm talking of ZOPE 2.6.0) so i had to make some changes in the code of ZPublisher/xmlrpc.py: def exception(self, fatal=0, info=None, absuri_match=None, tag_search=None): # Fetch our exception info. t is type, v is value and tb is the # traceback object. if type(info) is type(()) and len(info)==3: t,v,tb = info else: t,v,tb = sys.exc_info() # Don't mask 404 respnses, as some XML-RPC libraries rely on the HTTP # mechanisms for detecting when authentication is required. Fixes Zope # Collector issue 525. if t == 'Unauthorized' or (isinstance(t, types.ClassType) and issubclass(t, Unauthorized)): return self._real.exception(fatal=fatal, info=info) # Create an appropriate Fault object. Containing error information Fault=xmlrpclib.Fault f=None try: # Strip HTML tags from the error value v = str(v) remove = [r"<[^<>]*>", r"&[A-Za-z]+;"] for pat in remove: v = re.sub(pat, " ", v) from Globals import DevelopmentMode if DevelopmentMode: from traceback import format_exception value = '\n' + ''.join(format_exception(t, v, tb)) else: value = '%s - %s' % (t, v) ###### my own extension for catching user exceptions START ##### try: faultCode = getattr(sys.exc_info()[1],'faultCode') faultString = getattr(sys.exc_info()[1],'faultString') except: print "no according exception type" ###### my own extension for catching user exceptions FINISH ##### if isinstance(v, Fault): f=v ###### my own extension for catching user exceptions START ##### elif (faultCode and faultString) : f = xmlrpclib.Fault(faultCode,faultString) ###### my own extension for catching user exceptions FINISH ###### elif isinstance(v, Exception): f=Fault(-1, 'Unexpected Zope exception: %s' % value) else: f=Fault(-2, 'Unexpected Zope error value: %s' % value) except: f=Fault(-3, "Unknown Zope fault type") # Do the damage. self.setBody(f) self._real.setStatus(200) return tb By that way, I could send my own fault code and fault descriptions via XML-RPC. But as you can see, I have to extend ZOPE code, and I don't want to do it, I have to work with standard releases of ZOPE. Do you think that something like that would be improved in an early future for next ZOPE releases? Any opinion will be really appreciated. Thanks for advance. Regards. Aitor Illarramendi Amilibia Ingeniero de software Mando y Control <http://www.indra.es/> Indra.bmp Carretera de Loeches, 9 28850 - Torrejón de Ardoz, Madrid (ESPAÑA) Tel: +34-91-626.80.60 Fax: +34-91-626.81.14 aillarramendi(a)indra.es www.indra.es <http://www.indra.es/>

1 0

Session Event Listeners
by Beef a 27 Feb '03

27 Feb '03

Does anyone have any idea how to register session event listeners in Zope 2? This is a standard concept in Java/JSP/ASP et al. Basically it allows a method to be registered and executed when a http session is either created, lost or invalidated. Is there such a thing in Zope? Thanks -- Brian _________________________________________________________________ Express yourself with cool emoticons http://messenger.msn.co.uk

3 2

Following the Zope Collector
by Florent Guillaume 26 Feb '03

26 Feb '03

Hi, Currently the Zope collector is in "dispatcher On" mode, whereas the CMF and Zope3 collectors have "dispatcher Off". The difference, for those not familiar with Collector configuration, is that with dipatcher On only the few collector managers are notified by email of new issues in the collector (and are theoretically responsible for assigning them to Supporters), whereas in Off mode all the supporters receive the notification. As a supporter, I find that receiving a notification for each new issue is invaluable in tracking what the current problems are, and in having good response time on "easy" bugs. This works very well for the CMF collector, and I'm sure the Zope3 folks wouldn't want it any other way either. But currently I've no idea what's happening to the Zope collector unless I browse every entry on a regular basis to see what may have changed, which is very time consuming and impractical considering the number of entries. So I'd like to propose to switch the Zope collector to "dispatcher Off". This would mean more email traffic for the supporters, but it's easy enough to filter and I think the benefits are worth it. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com

3 3

ZLDAP and replication
by Jean Jordaan 26 Feb '03

26 Feb '03

Hi Jeffrey & all I'd just like to check something .. When running LDAP in a master/slave setup, if a client of the slave tries to update the directory, the slave returns a referral (pointing at the master) to the client, and the client has to retry the update at the master. That's steps 3 and 4 in this diagram: http://www.openldap.org/doc/admin20/guide.html#Replicated%20Directory%20Ser… It doesn't look like ZLDAPConnection does this, or am I being obtuse? -- Jean Jordaan http://www.upfrontsystems.co.za

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev February 2003