March 2001 - Zope-Dev

ZopeSecurityPolicy & this()
by Petr Knapek 28 Mar '01

28 Mar '01

Hi Zopists, I have now problem with executable content where this() is called. My problem: I have this structure in ZODB / |_ acl_users (Zope default) |_ dalmatin (ISNG Folder) * ownes user who is in role Manager from /dalmatin/acl_users |_ acl_users (Modified LDAPAdapter) |_ index (ISNG Document) ** ownes user who is in role Manager from /dalmatin/acl_users * ISNG Folder is my python product which is created from Folder ( ISNGFolder(Folder) ) ** ISNG Document is my python product, it is created from DTML Document ( ISNGDocument(DTMLDocument) ) In index I call this: <dtml-if "AUTHENTICATED_USER.hasRole('nextra.cz', this())"> ... and when I try to execute index also when I am in role Manager from /dalmatin/acl_users, an Zope error is raised that I am not autorized to access object this. Zope Error Zope has encountered an error while publishing this resource. Unauthorized You are not authorized to access this. Traceback (innermost last): File /usr/local/Zope-2.3.0-src/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /usr/local/Zope-2.3.0-src/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/Zope-2.3.0-src/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/Zope-2.3.0-src/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: index) File /usr/local/Zope-2.3.0-src/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: index) File /usr/local/Zope-2.3.0-src/lib/python/OFS/DTMLDocument.py, line 189, in __call__ (Object: index) File /usr/local/Zope-2.3.0-src/lib/python/DocumentTemplate/DT_String.py, line 538, in __call__ (Object: index) File /usr/local/Zope-2.3.0-src/lib/python/DocumentTemplate/DT_Util.py, line 328, in eval (Object: AUTHENTICATED_USER.hasRole('nextra.cz', this())) (Info: this) File /usr/local/Zope-2.3.0-src/lib/python/OFS/DTMLMethod.py, line 261, in validate (Object: index) File /usr/local/Zope-2.3.0-src/lib/python/AccessControl/SecurityManager.py, line 144, in validate File /usr/local/Zope-2.3.0-src/lib/python/AccessControl/ZopeSecurityPolicy.py, line 199, in validate Unauthorized: (see above) Can somebody help me to solve my problem with ZopeSecurityPolicy? Zope 2.3.0 (compiled from sources) on Debian -- Petr Knápek NEXTRA Czech Republic, s.r.o., Hlinky 114, 603 00 Brno, Czech Republic e-mail: mailto:petr.knapek@nextra.cz tel:+420-5-43 554 150 FAX:+420-5-43 554 214 "Perl is worse than Python because people wanted it worse." Larry Wall, 14 Oct 1998

1 0

Memory problems with ParsedXML ?
by Godefroid Chapelle 28 Mar '01

28 Mar '01

Hi, I have imported about 2500 xml files in ParsedXML objects through the use of : manage_addProduct['ParsedXML'].manage_addParsedXML(id, '', xmlString) This works perfectly. But when trying to browse the folder containing the ParsedXML instances, a whole lot of memory is used by Zope and it took my machine down. Have I done something wrong or does this info help you debug the product ? Hope this help. -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 30 1348 Louvain-la-Neuve Belgium Tel 010 457490 Mob 0477 363942 TVA 467 093 008 RC Niv 49849

1 0

Btree problems on recent CVS update..
by Steve Spicklemire 28 Mar '01

28 Mar '01

Hmm.. anybody seen this? -steve cc -fpic -I../Components/ExtensionClass/src -I../Components/BTree -I./ZODB -O -pipe -D_THREAD_SAFE -I/usr/local/include/python1.5 -I/usr/local/include/python1.5 -DHAVE_CONFIG_H -c ./../Components/BTree/BTree.c ./../Components/BTree/BTree.c: In function `BTreeItems_item_BTree': ./../Components/BTree/BTree.c:249: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c:249: (Each undeclared identifier is reported only once ./../Components/BTree/BTree.c:249: for each function it appears in.) ./../Components/BTree/BTree.c: In function `BTreeItems_item': ./../Components/BTree/BTree.c:299: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `bucket_index': ./../Components/BTree/BTree.c:471: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `_bucket_get': ./../Components/BTree/BTree.c:509: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `BTree_index': ./../Components/BTree/BTree.c:596: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `_BTree_get': ./../Components/BTree/BTree.c:647: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `_bucket_set': ./../Components/BTree/BTree.c:749: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `BTree_grow': ./../Components/BTree/BTree.c:961: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `_BTree_set': ./../Components/BTree/BTree.c:1028: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `bucket_keys': ./../Components/BTree/BTree.c:1099: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `bucket_values': ./../Components/BTree/BTree.c:1129: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `bucket_items': ./../Components/BTree/BTree.c:1159: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `bucket_clear': ./../Components/BTree/BTree.c:1209: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `BTree_clear': ./../Components/BTree/BTree.c:1265: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `bucket_getstate': ./../Components/BTree/BTree.c:1294: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `BTree_getstate': ./../Components/BTree/BTree.c:1759: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `BTree_elements': ./../Components/BTree/BTree.c:1851: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `Bucket_length': ./../Components/BTree/BTree.c:1986: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `BTree_length': ./../Components/BTree/BTree.c:2002: `cPersistenceCAPI' undeclared (first use in this function) ./../Components/BTree/BTree.c: In function `initBTree': ./../Components/BTree/BTree.c:2122: `cPersistenceCAPI' undeclared (first use in this function)

1 0

LoginManager question
by Bertrand Croq 28 Mar '01

28 Mar '01

Hi, I am currently using LoginManager to authenticate users from a MySQL database. I followed the tutorials and it works quite well; but there are other data associated with users in the database that I would like to use in Zope. I have found a solution but I think it is quite complicated: - first, I added SQL_id_user (ZSQL-method) in the acl_users: select id_user from user where <dtml-sqltest username column=user_name type=string> - then, I added id_user (DTML-method) in the acl_users: <dtml-in expr="SQL_id_user(username=username)"> <dtml-return id_user> </dtml-in> - now, when I want to get the id_user value associated with the current user, I need to do: <dtml-with REQUEST> <dtml-var expr = "AUTHENTICATED_USER.id_user( AUTHENTICATED_USER, username=AUTHENTICATED_USER )" > </dtml-with> Isn't there an easier way to get the id_user value? -- Bertrand Croq - VIRTUAL NET (http://www.virtual-net.fr) 80, avenue des Buttes de Coesmes - 35700 RENNES tel: +33 2 23 21 06 30 - fax: +33 2 99 38 16 85

2 2

Re: [Zope-dev] FTP interface being worked on?
by Karl Anderson 27 Mar '01

27 Mar '01

"Chris McDonough" <chrism(a)digicool.com> writes: > I don't think it's reasonable or wise to impose any "master > structure" for filesystem serialization of bodies of > objects. Each instance (or perhaps each class) should > define how best to serialize itself to disk. > Representations between classes are likely to be radically > different. A place for standardization is in the > "properties" file(s) which accompany each object rep... this > is likely to be XML or another structured variant. Is there a motivation for using serialization to provide an editable "god's eye view" of all or part of a Zope site? That is, provide a two-way XML serialization at any stage of the managed hierarchy of a site? That way, XML tools could be used as stream editors at any level, to the extent that the serialization is understandable. So, for example, we'd have ways to not just alter a template or content that gets templatized, but the containers that organize them, and related metadata or content that isn't as near. This links well with the standardization that you mention - objects can have arbitrary serialization formats, but if certain attributes that we're interested in are recognizable, those attributes could be edited on a containerwide level. So, if we had arbitrary objects that we wanted to have an effect on content or display, the same XML tools could be used to manage them all, limited only by the ability of those tools to slog through a level of the hierarchy. This is kind of stream-of-consciousness talk, and might be more silly than realistic; certainly, if the objects didn't guard how they could be updated, a misconfigured tool could waste them without warning. There's a similar project called psilib that was discussed in xml.com: <http://www.xml.com/pub/a/2000/03/22/psi/index.html> -- Karl Anderson karl(a)digicool.com

6 10

ANN: Zope Page Templates 1.0.0 beta 1
by Evan Simpson 27 Mar '01

27 Mar '01

The first beta release of ZPT is ready! Come read about them at http://dev.zope.org/Wikis/DevSite/Projects/ZPT, and download from http://www.zope.org/Members/4am/ZPT. These should be especially interesting for teams of Zope developers in which the programming and page/site design tasks are handled by separate people. Cheers, Evan @ digicool

1 0

Re: [Zope-dev] FTP interface being worked on?
by Karl Anderson 27 Mar '01

27 Mar '01

"Chris McDonough" <chrism(a)digicool.com> writes: > > > Are you thinking that we would build client-side tools to recognize an > XML > > > representation of a subpart of a site? > > > > Client-side tools, no. I'm thinking that exporting to XML would allow > > existing tools to recognize and manipulate a subpart of a site. > > Which ones? Parsers, transformers, etc.. I don't know of any end-user tools (are there any?), I'm talking about building blocks. > > Is there a particular set of tools or editing paradigms that we have > > in mind when we say that a non-XML representation is suited for client > > side tools? > > Yes.. anything that works well with diff and CVS and is recognizable by a > human. PythonScripts should be serialized to something that looks like a > regular Python script. Images should look like images, etc. The directory > tree generated should look as much as possible like a normal filesystem. Sure, I would use that, too, probably more than an XML representation, I'm referring to the ability to represent in other formats because of their usefulness and scalability. For example, if I were doing lots of random edits on a subtree of DTML files and Python scripts, I'd want them to look like a filesystem tree full of text files and I'd use emacs, grep, find, etc. on them. If I wanted to be able to use an automated tool to, say, update the spam and eggs fields of everyting in a subtree every friday, an XML parser and/or DOM tree and/or transform working on a single XML representation of the subtree checked out to the local filesystem seems like the easiest entry point. I'm probably straying from the proposal here. -- Karl Anderson karl(a)digicool.com

1 0

Zope/OpenBSD: Too many open files
by Ricardo Bermell 27 Mar '01

27 Mar '01

Zope (started from a shell) in OpenBSD gets locked too easyly because of the low default limit for open file descriptors (64). When Zope gets locked shows repeatedly this message "PROBLEM(100) ZServer warning: server accept() threw an exception", locking effectively also the console. Conditions in wich i have tested the problem: - OpenBSD 2.7 - Zope 2.3.0 - 'bash' shell How to reproduce the problem: 1. Anotate your current limit for open files (after this test you will want to restore this value): type "ulimit -a | grep 'open files'" My systems gives "open files 64" 2. If you want to crash zope sooner, set a lower limit (for example, 32) with "ulimit -n 32". 3. Start Zope from your shell (mine is 'bash') with zope 'start' script. Before, in the call to z2.py (in 'start') include option -D for 'debugging' (if not, all will be the same, exept that you won't see the "Problem(100)" message 4. Type "fstat | grep run-zope | grep stream | wc -l", (where 'run-zope' is the user account you use to run zope) or "fstat | grep 11789 | grep stream | wc -l" (where '11789' is the pid of zope process) That gives you the number of open streams for zope, which initially is 1. Each open stream consumes one file descriptor. 5. From a browser of another computer, open any (one) page of your zope site (http://your.zope.server:8080, where 8080 is the port you've open for zope). That will open 2 tcp streams in your server. Test, as before: "fstat | grep run-zope | grep stream | wc -l" This gives me 3 streams in total (1 initial + 2 for browser) 6. Close your browser and see how the open streams persists Type again: "fstat | grep run-zope | grep stream | wc -l" You will see 3 yet. 7. Repeat this operation many times (open browser, get http page, close browser), observing how the number of open streams increases in steps of 2. After m repetitions your browser does not get response from Zope: your Zope service and your console stops attending requests. 8. Stop your Zope from another console. (This liberates also the locked console) 9. Test distinct values for 'ulimit -n'. You will observe that, for a given value of 'ulimit -n' the number of repetitions (m) needed to hang your zope will be always the same. (You must run 'ulimit -n' _before_ run zope for it to get effect, not _while_ running zope) Questions which i'm not able to answer: - How many time an open tcp stream lives after you open a page from your browser? - How many time an open tcp stream lives after you close the browser (wich originated the stream)? the answer to those two questions will help to know: - How can i predict an adequate number for 'ulimit -n' (max. number of file/stream descriptors) in function of the utilization of my server? Unknowing wich is the perfect election, i've selected a limit of 1024 - Is it too many 1024? Too many resources utilization? But, the main question, IMHO, is that: - It is Zope robustness what fails. It should deny access gracefully when resources are exhausted. (Or at least, it should give comprehensive error information). Is it so? Or is it a wrong observation? I am now using zope only for developing static pages, not for a public dynamic service, and the 'ulimit' patch suffices, but i am afraid for when i'll want to put it in a public service with a heavy load. -- Ricardo P.S. I have tested also Zope 2.2.4 and 2.3.1b1 in OpenBSD. I didn't perform the 'ulimit' test in these versions but i do have experienced the "PROBLEM(100)" error (or similar). I have tested Zope 2.3.1b1 and 2.3.0 thru Apache and standalone. When thru Apache: with pcgi and with fastcgi. When with fastgi: with port and with socket.

1 0

Re: [Zope-dev] FTP interface being worked on?
by Karl Anderson 27 Mar '01

27 Mar '01

Chris McDonough <chrism(a)digicool.com> writes: > I think the only good reasons we have right now for having > filesystem-compatible serialization are to make Zope content editable via > common tools in a way that makes sense to people not used to (or comfortable > with) the object database, and to give people a plausible way to put a Zope > site under source control. > > Are you thinking that we would build client-side tools to recognize an XML > representation of a subpart of a site? Client-side tools, no. I'm thinking that exporting to XML would allow existing tools to recognize and manipulate a subpart of a site. I'm basically agreeing with you - "common tools" for manipulating text sounds like parsers to me. I'm not sure why XML is considered less readable than an unknown format for Zope object serialization; I guess I haven't seen what's being considered. But it seems to me that for humans, XML might lose by a little, but for any type of mediated or batch processing, XML wins by a lot. Parsers are standard enough that their APIs are easy to learn if you've played with them before. Random human-editable text formats sounds like StructuredText; when I think of StructuredText I think "simple DOM serialization". Is there a particular set of tools or editing paradigms that we have in mind when we say that a non-XML representation is suited for client side tools? This is the way that Manila seems to be doing it: http://www.thetwowayweb.com/theXmlFiles -- Karl Anderson karl(a)digicool.com

3 2

filter metatypes in objectmanager
by Magnus Heino 27 Mar '01

27 Mar '01

How can I control what meta_type's that can be added to an ObjectManager? If you create a ZClass that inherits from ObjectManager, you can specify this, but how is it done from a python product? /Magnus

2 1