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

Toby Dickenson tdickenson@geminidataloggers.com
Thu, 11 Apr 2002 09:51:46 +0100


On Wednesday 10 April 2002 5:07 pm, Brian Lloyd wrote:
>> >> should not accept REQUESTs with REQUEST_METHOD "GET".
>> >
>> >This is hard, hard, problem. While some good ideas have been
>> >proposed, there is not really a quick fix that doesn't have
>> >some downside that some group somewhere considers a
>> >showstopper :(
>>
>> I agree Olivers suggestion is not a total solution, but does it have a
>> showstopper problem?
>
>Only if you happen to have an application deployed and might
>ever want to upgrade your Zope installation without having to
>do a total code audit :^)


OK, heres a more specific proposal:

1. Add a method to ClassSecurityInfo declareNonIdempotent('methodName')

2. Add this declaration to ZMI methods which create, delete, or change 
content. (It also needs to get added to object constructors, but not the 
pre-constructor form. Im not sure exactly how to do that yet)

3. Change ZPublisher to not allow GET requests on non-idempotent methods. 
(This probably affects DAV and FTP too)

4. Change dtml to not allow <dtml-var someNonIdempotentMethod>, although it 
should still allow <dtml-var "someNonIdempotentMethod()">


How many problems would this cause.....

a. It affects anywhere in the ZMI which currently use GET when they should be 
using POST. I suspect we would already know about such cases, because it 
would also cause problems when accessing the ZMI through a cache.

b. It affects any pages in other products that link to the ZMI using GET 
reqests. In a quick audit of my server logs I see I am doing this at least 
once; I have a script that uses a GET request to restart the server.

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.


On balance, I think it might be worth building a prototype.