Re: [Zope-dev] Two small ZPT suggestions
On July 17, Toby Sargeant wrote: > > > ... > ... > ... > > Why bother with the tal:define? Just: ... ... ... which is just a direct translation of the corresponding Python: for row in rows: if row.rowtype=='group': # etc a. -- Adrian van den Dries [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au ___ 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] Two small ZPT suggestions
Hi, I must preface by saying that I'm relatively new to ZPT, and haven't been using it in the context of Zope. Having said that, however, I think that what follows is still applicable. Two things that have struck me as potentially useful additions have been a syntax for expressing case statements and arguments to macros (slots are useful, but aren't applicable when, for instance, you want to write a macro to mark up an arbitrary object). Both of these are essentially syntactic sugar, but (imho) improve readability and aid brevity. The syntax I have come up with (and have an implementation for) is as follows: case statements: two new attributes are added: tal:switch and tal:case. as an example: ... ... ... compare: ... ... ... This is essentially the same as using tal:define and multiple tal:condition blocks, except for the fact that the case values aren't part of the visible variable space. Missing at the moment are: * ways to change the type of comparison used in the case test. * a sensible definition of how a default case should work. (this is actually pretty obvious, but would require more work, as the case statements can't be simply treated like conditionals) macro arguments: metal:use-macro tags allow metal:arguments="define_list" which defines a set of variables in a new local scope in which the macro is executed. if tal:define could be used in conjunction with metal:use-macro in such a way as to have the define executed first, then the additional tag wouldn't be required. My reading of the docs suggests that there's reason for the ordering of excution of tal: and metal: tags, so the new tag may well be the only way. compare: Toby. pgp0.pgp Description: PGP signature
Re: [Zope-dev] stopping the Version DoS
Leonardo Rochael Almeida wrote: > I didn't check the sources to see what solution was finally given to the > Version DoS attack, but I have a suggestion. Jim commited a fix, which AFAICT, puts the issue to rest. What his fix does is simply remove the version's db connections from the pool if the connecting user doesn't provide correct authorization creds. This sort of trades off 1 DoS for another if you want to get picky about it; now anonymous users can remove a version's db connections at will. Evidently, creating connections isn't expensive enough for this to really matter though, so I think the issue can be considered closed. Personally I'm just removing version support entirely from my tree. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer ___ 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] WebDAV interoperability event
I just stumbled across this... I think it would be really cool if there was a zope presence. http://www.webdav.org/other/interop03/ -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's PORPOISE MADE OF BUTTER! (random hero from isometric.spaceninja.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] stopping the Version DoS
Hi, I didn't check the sources to see what solution was finally given to the Version DoS attack, but I have a suggestion. The problem, IIUC, is that Zope needs to decide whether the Version informaton it's receiving is valid without having access to ZODB data. My suggestion is to disable Versions unless Zope is started with the ENVVAR (or ZConfig var) VERSION_KEY, which is a password used to hash the Version info. In this case, the version cookie would be generated like this Zope-Version = :MD5(:VERSION_KEY) This way the connection machinery doesn't need to open the connection in order to verify that Zope-Version was generated from a real version object. The only way to abuse the Version system is by knowing VERSION_KEY. Looking at the cookie itself will only allow an attacker to open the same version, but even this can be avoided if we put an expiration time in the cookie value and encode it in the signature part as well: Zope-Version = ::MD5(::VERSION_KEY) Variants of this include putting the auth info in a different cookie (Zope-Version-Auth), using SHA instead of MD5 to make it stronger, base64 encoding the binary flavor of the digest digest instead of using the hexdigest to make the cookie smaller, etc. Cheers, Leo PS: I can help coding this if anyone can help me get my subscription to zope-coders going (I tried subscribing but nothing happened) and checking why my public key isn't working to get a Zope checkout (my zope.org login is LRA) :-) ___ 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 )
