"""Excuse me for saying, but this is all slightly nuts.
Is there some reason you're being so (overly) paranoid?


I don't know Zope well, even though I have been using Chris's excellent 
Squishdot product for three years at Goodbyejim.com. Chris has moved on to 
other Zope activities and has not upgraded Squishdot since 2001. That is a 
blessing in disguise, because it is time to write my own Zope 2.10 blogging 
product that relies on Web 2.0 concepts of using third parties and web 
standards (Haloscan, Atom, CSS ZenGarden, Cheetah templating) to provide what 
was built in to Squishdot. 

As many of us know, BDFL Guido doesn't seem to think much of Zope. He allegedly 
feels that Zope forces one to learn Zope instead of Python. There is some truth 
to that. My goal is to leverage Zope's ZMI and CMS features while doing as much 
work as possible in Python and Python scripts. 

I thus object philosophically to ZPT and DTML and hope to avoid them in my 
product, which should be released on Zope.org to a probably indifferent Zope 
world some time later this year. I can use Cheetah as an external method with 
Python scripts, instead of ZPT and DTML. 

My attempt to use Chris's Twiddler templating tool as an external method 
instead of Cheetah ran into a problem which I am sure was my fault, although 
Twiddler worked great from my Zope instance's Python command line. I didn't 
feel like figuring out what my mistake was. The Path of Least Resistance was to 
use Cheetah, and I believe that there is great wisdom in the Path of Least 
Resistance. Deviate from that path only to travel on the Path of Greater 
Wisdom. Twiddler and Cheetah appear equally wise, so PLR said go with Cheetah.

I want as much as possible of my Zope 2.10 blogging product (working name, 
Aristede, for which I own the Aristede.com domain name) to be visible in Python 
scripts and folder properties. External methods should be only a wrapper to 
Cheetah and to other Python modules that can't be imported into Python Scripts.

My paranoid nature is due to a fear of creating my own product and finding out 
that I have left a security hole. By using Eval in my external method I can 
avoid coupling the external method which calls Cheetah to the list of 
properties which I send Cheetah, and reduce the amount of code which I need to 
do it. But Eval is super dangerous to use. It is a trade-off between code 
simplicity and security. 

Hence my desire to make certain that no one can pass from inside a URL 
parameters which are later Eval'd to my external method.

I accept Chris's assurance that the Proxy tab in the ZMI is robust. And that if 
someone is able to crack it I could get Zope developers to fix it. That is 
sufficient for a blog application. It may not be sufficient for a medical 
records or a banking application, but I am not writing one of those. 

Therefore I will use the ZMI to restrict my external method to authenticated 
users. I will use the ZMI to proxy-as-authenticated the Python Script which 
calls the external user. That will be sufficient.
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to