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

[Oliver Bleutgen]

First, Toby, thanks for that proposal, it's indeed far more elegant than 
the mess I had in mind.

Casey Duncan wrote:
> Toby Dickenson wrote:
> [snip]
> 
>> 4. Change dtml to not allow <dtml-var someNonIdempotentMethod>, 
>> although it should still allow <dtml-var "someNonIdempotentMethod()">
> 
> 
> Ahhh!
> 
> How do you propose to do that? I see a lot of bruised foreheads 
> resulting from this...

Maybe we don't need that point, because methods declared nonIdemPotent 
(maybe we should call it disallowGET?) would fail anyway if they had 
been passed the original REQUEST.

> 
>> How many problems would this cause.....
> 
> [snip]
> 
>>
>> c. It affects code that uses <dtml-var someNonIdempotentMethod> to 
>> call a method with no parameters. I have no idea how common that would 
>> be.
> 
> 
> Likely very common.

Are you sure? But anyway, this checking also could be disabled (or - 
upgrade path friendlier - enabled) by a command line switch (or a config 
file). Anybody could check their own Sites/Products just by enabling the 
checking. I for one would consider it a bug if my application failed 
with a zope behaving like the authors of the http rfc are recommending.

>> On balance, I think it might be worth building a prototype.
> 
> 
> Best of luck to you.

My personal opinion is that it might be ugly and potentially cause 
problems with the upgrade path now, it will get even worse the more 
features zope gets. I suspect the question of the request method will 
get more important, as more and more protocols use HTTP as a transport.
So perhaps at least the first point of toby's proposal - or something 
functionally equivalent - could be implemented (adding this method to 
ClassSecurityInfo), which wouldn't hurt anyone, but give application 
writers the chance to use this feature.

cheers,
olive