[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.