[Zope-dev] [RFClet]: What about the request method and the client side trojan?

[Toby Dickenson]

On Thursday 11 April 2002 5:16 pm, Casey Duncan wrote:

>The most troublesome case is where foo accepts any number of arguments
>(such as a DTML method or ZPT or any other method with **kw), and you
>cannot know whether it changes objects or simply returns some string or
>something.

Yes, that is a limitation of my proposal. It doesnt cover non-idempotent DTML 
and ZPT. (DTML and ZPT is idempotent by definition when used for presentation 
logic.)

I dont think that limitation is fatal.

> I don't think it is helpful to assume that "because a method
>takes arguments, it is dangerous". I can write destructive methods that
>take no arguments too.

Sure you could. Lets assume you have, and have declared it non-idempotent as 
described in my proposal.

Firstly, you would not be calling it from DTML or ZPT if you were using those 
only for presentation logic. presentation logic by definition cant be 
destructive.

Anyway, even if you were writing a destructive DTML method, I bet you would 
write it as one of:

<dtml-call my_destructive_method>
<dtml-call "my_destructive_method()">
<dtml-var "my_destructive_method()">
<dtml-in "my_destructive_method()">
<dtml-with "my_destructive_method()">

but not:

<dtml-var my_destructive_method>
<dtml-in my_destructive_method>
<dtml-with my_destructive_method>

Those last three forms are today legal. My proposal would make them an error, 
but only because your new destrucive method has been declared non-idempotent.

I think thats an improvement, but only a slight one. It is much less 
important than Oliver's original proposal which was to control methods called 
by ZPublisher, not by DTML. I would be happy to go with a reduced proposal 
that leaves DTML unchanged, and made it an error to issue a GET request for 
http://host/path/my_destructive_method (but only because my_destrucive_method 
has been declared non-idempotent)


>Also, are we talking about only fixing the "action on GET" for the ZMI
>or for all Zope apps?

Much like when new style security declaration were introduced. Initially only 
ZMI had them, but new products could use them too.

>If I were to implement this, a very simple approach seems attractive:
>Lock the ZODB on GET requests so that no transactions can be committed.
>However, I'm not sure I want to go there.

Hmmmm. I wonder whether read-only transactions could be the basis for a 
ZODB optimisation.......