August 2002 - Zope-Dev

Add audio to slides online - free 3 day trial
by Tim Dobson - www.presentationcreator.co.uk 20 Aug '02

20 Aug '02

Hi We have created an online presentation creator system that adds audio to powerpoint slides by using the internet and a telephone. This makes it easy to produce media rich, instant training courses and sales presentations. After recording audio (via your phone) the presentation/course gets published immediately and you can invite your audience to participate by email. To see a demo right now AND get a free trial to create presentations and courses yourself, complete the form and we will send you your free trial account details http://prescreator.brinkster.net/corpenquiry_form.htm By the way, you might want to have an existing powerpoint presentation at hand when you try the software. If you have a questions call uk 00 44 (0) 207 384 9696. Have fun! Regards Andy Gadd timd(a)presentationcreator.co.uk Presentation Creator London House 100 New Kings Road London SW6 4 LX Tel 0207 384 9696 Fax 0207 731 8199 www.presentationcreator.co.uk

1 0

RE: [Zope-dev] PathIndex doesn't index last part of path
by sean.upton＠uniontrib.com 20 Aug '02

20 Aug '02

If the question is begged, why use the catalog: for folders with thousands of objects, applications like CMF skins can be amazingly slow using ObjectManager methods and CMF-wrapped equivalents; they also do not provide sorting. For applications like this, both containment and flexible query support (sorting) are important. Use-case: thousands of objects in a Portal Folder. CMF Skins like Plone use ObjectManager based methods to get a list of siblings in a sidebar. When you have 1000+ items in the folder, the fact that this takes 2 minutes on an Athlon 2000+/1GB server, isn't batchable, and isn't sortable is sort of sad. Use of the Catalog makes much more sense here (I can sort, and the performance penalty is low, so I can take a slice of the resulting sequence of brains, and do getObject() over each one; even if a container could be improved performance wise to have a quick objectIds() method, ObjectManager interfaces have no mechanism to specify sorting based on metadata like you could do with a Catalog query). One thing that seems to be feature-broken about PathIndexes, though, is the lack of ability to specify a depth (not level, but depth of a match, for example, to specify items). Above and beyond support for a specific place within a hierarchy, there needs to be a simple mechanism to support query for an absolute path, and only objects directly matching that path, or directly contained within that path. The workaround for this is to add a custom FieldIndex that indexes the string value of the path of the items container, and this requires putting a python script in the root of a CMF portal, for example, that is acquired by all indexed content. It would be nice if the PathIndex machinery could do this out of the box. http://lists.zope.org/pipermail/zope-cmf/2002-August/014167.html http://lists.zope.org/pipermail/zope-cmf/2002-August/014204.html Sean -----Original Message----- From: Casey Duncan [mailto:casey@zope.com] Sent: Friday, August 16, 2002 4:55 PM To: Andy McKay; zope-dev(a)zope.org Subject: Re: [Zope-dev] PathIndex doesn't index last part of path A PathIndex is designed to make it more efficient to aggregate objects at various levels of containment. Their primary use case AFAIK is to allow to to limit queries to particular places within a hierarchy. The idea is to eliminate recursive searching of leaf level folders when you want all objects under a higher level and its child levels. Also, by not indexing the nodes themselves, the index is an order of magnitude smaller and searches are therefore faster and it takes less room and is faster to update. In fact there is no need to index the entire path of an object in the catalog. Even with no Indexes defined, ZCatalog already does this for you. The uid of every entry in the catalog is the full path to the object (as a string). Unfortunately, ZCatalog does not expose this to the surface but you can write a trivial external method to do it. And I might entertain adding a ZCatalog API to do so if I had a good use case. Right now you can only access entries by RID. Now that begs the question, If you already know the path to the object you are looking for, why are you using the Catalog in the first place? I highly doubt doing what you describe below is faster than just directly accessing the object. In fact I'd be willing to be its slower, especially since you are searching two indexes to get it. Unless of course these are dynamically generated objects of some kind (no stored in Zope). As for making RIDs more permanent, that would basically require a rewrite of the Catalog, and make certain operations much more expensive. As it stands, your application should only assume that RIDs are valid within a single transaction. You should use the path to uniquely identify objects, or some application defined uid that gets cataloged otherwise. -Casey ----- Original Message ----- From: "Andy McKay" <andy(a)agmweb.ca> To: <zope-dev(a)zope.org> Sent: Saturday, August 17, 2002 6:22 PM Subject: [Zope-dev] PathIndex doesn't index last part of path > This is mostly a question for AJ, but any input would be great. This bug bit > me today and is documented here: > http://collector.zope.org/Zope/449/ISSUE_TRANSCRIPT/view > > I dont understand the brief argument against this one, it would make sense > to me to able to pull an object out of the catalog based on its path. For > example if I want /foo/bar/blammo, currently this means there is only one > way of pulling the an object of the catalog given this path. Thats to send > (path='/foo/bar', id='blammo'), rather than (path='/foo/bar/blammo'). Why > wouldnt we want it this way? > > One thing I have done is store a whole bunch of references to objects as > selected by the user. These are essentially random objects and the quickest > way is to pull them back out of the catalog. Of course I cant do more than > one object per query (unless Im missing some other way) Id love to do > (path=['/foo/bar/blammo', '/foo/bar/blammoz']) and get these 2 objects... I > think that would be neat. > > It would seem data_record_id_ is not guaranteed to permanent after a > reindex_object (which CatalogAwareness uses), since this uncatalog and then > recatalogs the object. If this did work it would be cool and I could undo > all the changes to my app back again. > > - The patch is already there, so Im curious why do we have what seems to be > a more limited design? > - Would a halfway option such as path_match='final' be a choice that wont > break any code but would confuse everyone and not make into the > documentation? > - Is it just a matter of fixing reindex_object as was suggested on #zope so > that data_record_id_ is more permanent? > > Cheers > -- > Andy McKay > Agmweb Consulting > http://www.agmweb.ca > > > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > _______________________________________________ Zope-Dev maillist - Zope-Dev(a)zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )

2 1

Patch for 525, oops
by Brad Clements 19 Aug '02

19 Aug '02

add import types to the modified xmlrpc.py Brad Clements, bkc(a)murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax AOL-IM: BKClements

1 0

DTML and REQUEST data changes about to be checked in
by Martijn Pieters 19 Aug '02

19 Aug '02

Hi folks, I am about to land some big changes in the way DTML deals with data taken from the REQUEST object when accessed implicitly, in both the Zope Trunk and the Zope 2.5 branch. These changes could potentially break existing Zope sites. Without these changes, Zope is somewhat vulnerable to cross-scripting attacks, where a well-crafted URL can cause a Zope server to serve out arbitrary HTML. Because DTML does not automatically html quote any data, and can implicitly get information out of the REQUEST even when it was not the intention of the template author, it is easy to cause REQUEST data to be rendered as HTML on a page. My changes cause the REQUEST to keep track of suspected strings, where suspect is defined as any string with a '<'. These are marked as tainted. Any normal, explicit access to the REQUEST will still give you normal values. However, as soon as a DTML template requests a variable from the general namespace, and this variable is then satisfied from the REQUEST, the value of this variable could potentially be a TaintedString object instead of the original string. When rendering such a value, DTML will automatically HTML quote it if not already done so explicitly. All DTML string operations dealing with TaintedString objects are careful to retain the TaintedString status. I also fixed all exceptions raised in Zope that I could find, where untrusted REQUEST data was used in the exception message; these exceptions now html quote the data. I also made sure that the REQUEST calculated variables URLx and BASEx and such were not shadowed by untrusted form variables of the same name. These changes can break existing sites in the following ways: - If you relied on getting HTML-like data from the REQUEST in DTML and want to render this as HTML, and you got this data implicitly, this data will now be HTML quoted. Note that you were vulnerable to a cross-scripting attack here already. You can retrieve your information from the REQUEST directly (with <dtml-with REQUEST> for example), at your own risk. ;) - HTML quoting will also take place in templates that do not otherwise generate HTML to be sent back to the browser, such as email forms and Z SQL Methods. For Z SQL Methods, <dtml-sqlvar> does not quote TaintedStrings and is otherwise ignorant of them. For emails, use explicit access to REQUEST instead. - If you relied on being able to override URLx or BASEx variables through a form variable, this no longer works. Use explicit access to REQUEST.form instead. - Using the string method .join (''join(items)) cannot handle TaintedString objects. You can use _.string.join instead. - Passing a TaintedString value from a DTML template to other objects such as Python code, External Methods, Python Scripts, etc, may cause them to break because they did not anticipate a TaintedString object. What doesn't break (among others): - Accessing REQUEST data from Python code, Python scripts, or ZPT. Only DocumentTemplate.DT_String derivatives (DTML Document, DTML Method, etc) and DTMLFile objects are affected. - If you already HTML quoted, nothing gets double quoted. - Using the _.string module in DTML retains taints. - Zope 2.6 unicode marshalling (var:ustring:utf8) works with TaintedStrings as well. TaintedString objects try to mimic strings as best as they can, but until we move to python 2.2 definitely and we can inherit from str directly, certain python code will not accept TaintedString objects as substitutes. I found that the normal string module, and the string ''.join module don't accept TaintedString objects for example. Also, using the string interpolation operator % will cause TaintedString objects to be unwrapped. When TaintedString becomes a subclass of str, more operations will unwrap them, such as unicode() and ''.join; or just about any operation that manipulates strings through other ways than string methods. Because of size of the change and the impact on existing DTML code, well release betas of Zope 2.5 and 2.6 soon to facilitate wider testing. For those following CVS, please test the changes rigorously and let me know what you find. -- Martijn Pieters | Software Engineer mailto:mj@zope.com | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------

13 27

Re: pdf - "Files" not viewable
by Markus Stoll 19 Aug '02

19 Aug '02

This bug has been reported quite often and is still there. I debugged this one and here are my findings: The reason behind this is the range optimization, that sorts requested http ranges in ascending order (done in OFS/Image.py and ZPublisher/HTTPRangeSupport.py) The acrobat plugin is definitely unhappy with these sorted ranges that Zope uses for creating the response. Acrobat expects the ranges in the very same order it has requested them. RFC 2068 is unclear on this point, so I would consider it at least questionable whether range sorting is allowed. As some clients do not work with sorted ranges it should probably be considered as evil. I suggest the following bugfix: http://www.zope.org/Members/must/Zope_HTTPRange-patch This patch applies to Zope 2.4.4 and inhibits any range optimization. The Acrobat plugin will display pdf files without any problems after applying this patch. Markus Stoll -- E-Mail: markus.stoll(a)junidas.de Web: http://www.junidas.de/

3 3

Can't followup to bug 525 - Collector problem, DIFF attached
by Brad Clements 19 Aug '02

19 Aug '02

I'm trying to submit a patch to collector item 525 After I login, I select "followup" and enter text and path to the patch file. When I hit submit, I'm prompted to login again. If I do login again, I get a very ugly Zope error, most likely because the attached file isn't in the redirected request. Here's the diff with Zope 2.5.1 to "fix" this problem by redirecting unauthorized exceptions to the real HTTPResponse object *** orig-251/xmlrpc.py Mon Aug 19 09:15:28 2002 --- xmlrpc.py Mon Aug 19 09:23:05 2002 *************** *** 22,27 **** --- 22,29 ---- import sys from HTTPResponse import HTTPResponse import xmlrpclib + + from zExceptions import Unauthorized def parse_input(data): """Parse input data and return a method path and argument tuple *************** *** 118,124 **** # traceback object. if type(info) is type(()) and len(info)==3: t,v,tb = info else: t,v,tb = sys.exc_info() ! # Create an appropriate Fault object. Unfortunately, we throw away # most of the debugging information. More useful error reporting is # left as an exercise for the reader. --- 120,130 ---- # traceback object. if type(info) is type(()) and len(info)==3: t,v,tb = info else: t,v,tb = sys.exc_info() ! ! if t == 'Unauthorized' or t == Unauthorized or ( ! isinstance(t, types.ClassType) and issubclass(t, Unauthorized)): ! return self._real.exception(fatal=fatal,info=info) ! # Create an appropriate Fault object. Unfortunately, we throw away # most of the debugging information. More useful error reporting is # left as an exercise for the reader. Brad Clements, bkc(a)murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax AOL-IM: BKClements

1 0

PathIndex doesn't index last part of path
by Andy McKay 18 Aug '02

18 Aug '02

This is mostly a question for AJ, but any input would be great. This bug bit me today and is documented here: http://collector.zope.org/Zope/449/ISSUE_TRANSCRIPT/view I dont understand the brief argument against this one, it would make sense to me to able to pull an object out of the catalog based on its path. For example if I want /foo/bar/blammo, currently this means there is only one way of pulling the an object of the catalog given this path. Thats to send (path='/foo/bar', id='blammo'), rather than (path='/foo/bar/blammo'). Why wouldnt we want it this way? One thing I have done is store a whole bunch of references to objects as selected by the user. These are essentially random objects and the quickest way is to pull them back out of the catalog. Of course I cant do more than one object per query (unless Im missing some other way) Id love to do (path=['/foo/bar/blammo', '/foo/bar/blammoz']) and get these 2 objects... I think that would be neat. It would seem data_record_id_ is not guaranteed to permanent after a reindex_object (which CatalogAwareness uses), since this uncatalog and then recatalogs the object. If this did work it would be cool and I could undo all the changes to my app back again. - The patch is already there, so Im curious why do we have what seems to be a more limited design? - Would a halfway option such as path_match='final' be a choice that wont break any code but would confuse everyone and not make into the documentation? - Is it just a matter of fixing reindex_object as was suggested on #zope so that data_record_id_ is more permanent? Cheers -- Andy McKay Agmweb Consulting http://www.agmweb.ca

4 10

Re: 2seks
by Elgin C 16 Aug '02

16 Aug '02

Hic bir yerde bulup izleyemeyeceginiz icerigi size http://www.2seks.com sunuyor. TURK VE AVRUPALI AMATOR KIZLAR BULGAR KIZLARI ROMEN HATUNLAR TURK TECAVUZ FILMLERI KIZLAR YURDU ALMANYA'NIN SAPIK HATUNLARI OTELDEKI GIZLI KAMERALAR VE DAHASI... Hepsi orjinal ve kaliteli kayitlar. Hemen giris yapin ve tadini cikartin http://www.2seks.com

1 0

Bug Day 8/02 recap
by Matt Behrens 16 Aug '02

16 Aug '02

Zope Bug Day August 2002 was an unqualified success, with our largest bug total squashed to date: 45! The number of still-open collector issues dropped by almost 25%. Thanks to all those who participated! More information on Zope Bug Days can be found at http://dev.zope.org/CVS/BugDays. I think it would be good to hold another one in September; how's the 11th at 9 AM US/Eastern? (For the curious, we squashed #101, #115, #121, #46, #129, #27, #297, #29, #148, #461, #497, #38, #501, #106, #453, #69, #37, #40, #74, #95, #82, #507, #53, #168, #408, #81, #83, #90, #93, #104, #113, #61, #117, #127, #132, #134, #152, #268, #192, #13, #92, #179, #177, #518, AND #332.) -- Matt Behrens <matt.behrens(a)kohler.com>

6 5

XMLRPC and Basic Auth problems
by Tim Hoffman 16 Aug '02

16 Aug '02

Hi I am working on a project that uses XWT (xwt.org) as a frontend to Zope. XWT uses XMLRPC to communicate with a backend (in this case Zope). XWT expects an Error 401 is authentication is required on an XMLRPC call, so that it can negotiate the correct auth method The author of XWT sent the following email to me >Tim, I've got a piece of the answer -- your server needs to return an >HTTP 401 (Unauthorized) if no username/password is provided. This >response includes the challenge that XWT needs in order to build an >authentication request (realm, digest nonce challenge, etc). However what Zope is doing is sending back a <fault> in the XMLRPC <methodResponse> packet. So it appears to me that Zope doesn't send a http response 401 for XMLRPC (over http), but will send a 401 back to the browser. XMLRPC doesn't say anything about authentication, so I suppose either method is acceptable. However because XMLRPC is implemented on top of http, I would have thought a http approach (ie error 401) would be used. It appears that this behaviour is fundamental to Zope and is not an artifact of cookie auth in CMF etc.. Is this really correct behaviour ? Regards Tim Hoffman

3 7