Is there any way to turn off the publishing of external methods to the web in Zope?
I have an external method which uses eval(). I would like to prevent anyone from calling this method from inside a URL, e.g., myzopesite/myexternalmethod?myvar=deletemyfiles() Rather, I wish for only Zope objects such as Python Scripts to be able to call this external method. Is there any way to turn off the publishing of external methods to the web in Zope?
--On 26. Januar 2007 10:29:08 -0500 "Mark, Jonathan (Integic)" <jonathan.mark@integic-hc.com> wrote:
I have an external method which uses eval(). I would like to prevent anyone from calling this method from inside a URL, e.g., myzopesite/myexternalmethod?myvar=deletemyfiles()
Rather, I wish for only Zope objects such as Python Scripts to be able to call this external method. Is there any way to turn off the publishing of external methods to the web in Zope?
The standard Zope security also apply to external method. Configure the View permission according to your needs. -aj
The relevant permission for an external method in 2.10.1 is "Access contents information." The problem is that the Zope application which calls my External Method from a Python Script always runs unauthenticated. I turned off in the ZMI my External Method's access for unauthenticated users, and left it on for "Owner." However, now users who call the Python Script which calls the External Method also get prompted for authentication. I need unauthenticated users to be able to run the calling Python Script. I wonder if there is some way for unauthenticated users of a Python Script to be dynamically assigned a Zope role at the start of the Python Script and then lose that role at the conclusion of the Python Script. Is that inherently unsafe even if it is possible? -----Original Message----- From: Andreas Jung [mailto:lists@zopyx.com] Sent: Friday, January 26, 2007 10:36 AM To: Mark, Jonathan (Integic); zope@zope.org Subject: Re: [Zope] Is there any way to turn off the publishing of external methods to the web in Zope? --On 26. Januar 2007 10:29:08 -0500 "Mark, Jonathan (Integic)" <jonathan.mark@integic-hc.com> wrote:
I have an external method which uses eval(). I would like to prevent anyone from calling this method from inside a URL, e.g., myzopesite/myexternalmethod?myvar=deletemyfiles()
Rather, I wish for only Zope objects such as Python Scripts to be able to call this external method. Is there any way to turn off the publishing of external methods to the web in Zope?
The standard Zope security also apply to external method. Configure the View permission according to your needs. -aj
----- Original Message ----- From: "Mark, Jonathan (Integic)" <jonathan.mark@integic-hc.com> To: "Andreas Jung" <lists@zopyx.com>; <zope@zope.org> Sent: Friday, January 26, 2007 2:06 PM Subject: RE: [Zope] Is there any way to turn off the publishing of externalmethods to the web in Zope?
The relevant permission for an external method in 2.10.1 is "Access contents information."
The problem is that the Zope application which calls my External Method from a Python Script always runs unauthenticated. I turned off in the ZMI my External Method's access for unauthenticated users, and left it on for "Owner." However, now users who call the Python Script which calls the External Method also get prompted for authentication.
I need unauthenticated users to be able to run the calling Python Script.
I wonder if there is some way for unauthenticated users of a Python Script to be dynamically assigned a Zope role at the start of the Python Script and then lose that role at the conclusion of the Python Script. Is that inherently unsafe even if it is possible?
You can assign a Proxy role to your python script, but this may not solve your problem as anyone who can access the python script will be able to execute the external method that the python script calls. Jonathan
Using a proxy role on the calling Python Script worked. My guess is that a clever hacker could call the Python Script continually and then create a race condition that would permit him to call the External Method directly in a URL, thus passing the External Method his own malicious parameters. However, for now Proxy is sufficient. Thanks. -----Original Message----- From: Jonathan [mailto:dev101@magma.ca] Sent: Friday, January 26, 2007 2:06 PM To: Mark, Jonathan (Integic); Andreas Jung; zope@zope.org Subject: Re: [Zope] Is there any way to turn off the publishing of externalmethods to the web in Zope? ----- Original Message ----- From: "Mark, Jonathan (Integic)" <jonathan.mark@integic-hc.com> To: "Andreas Jung" <lists@zopyx.com>; <zope@zope.org> Sent: Friday, January 26, 2007 2:06 PM Subject: RE: [Zope] Is there any way to turn off the publishing of externalmethods to the web in Zope?
The relevant permission for an external method in 2.10.1 is "Access contents information."
The problem is that the Zope application which calls my External Method from a Python Script always runs unauthenticated. I turned off in the ZMI my External Method's access for unauthenticated users, and left it on for "Owner." However, now users who call the Python Script which calls the External Method also get prompted for authentication.
I need unauthenticated users to be able to run the calling Python Script.
I wonder if there is some way for unauthenticated users of a Python Script to be dynamically assigned a Zope role at the start of the Python Script and then lose that role at the conclusion of the Python Script. Is that inherently unsafe even if it is possible?
You can assign a Proxy role to your python script, but this may not solve your problem as anyone who can access the python script will be able to execute the external method that the python script calls. Jonathan
----- Original Message ----- From: "Mark, Jonathan (Integic)" <jonathan.mark@integic-hc.com> To: "Jonathan" <dev101@magma.ca>; <zope@zope.org> Sent: Friday, January 26, 2007 2:32 PM Subject: RE: [Zope] Is there any way to turn off the publishing of externalmethods to the web in Zope?
Using a proxy role on the calling Python Script worked. My guess is that a clever hacker could call the Python Script continually and then create a race condition that would permit him to call the External Method directly in a URL, thus passing the External Method his own malicious parameters.
That's why i suggested, in an earlier response, a URL test within the external method. Jonathan
I will add the URL test. In addition, I will pass a long symettric 64 bit key to the external method as a parameter, and require the external method to confirm that the correct key was passed. Since only I have access to my file system and to my ZMI this is sufficient. Extraneously, I would like to say how excited I am about the willingness of Zopistas to respond to questions from an ordinary user like me. Everyone talks about the buzzword frameworks Django and RoR. But the most important factor for a user ought to be the ability to get support online. On this point I don't see how Zope could be much better, as long as we ordinary users don't abuse it. Zope Corporation is opening an office in Northern Virginia, and that says to me that the commercial Zope community is growing. If I apply myself then maybe in a few years I would be part of it myself. Just my two shekels. -----Original Message----- From: Jonathan [mailto:dev101@magma.ca] Sent: Friday, January 26, 2007 2:30 PM To: Mark, Jonathan (Integic); zope@zope.org Subject: Re: [Zope] Is there any way to turn off the publishing of externalmethods to the web in Zope? ----- Original Message ----- From: "Mark, Jonathan (Integic)" <jonathan.mark@integic-hc.com> To: "Jonathan" <dev101@magma.ca>; <zope@zope.org> Sent: Friday, January 26, 2007 2:32 PM Subject: RE: [Zope] Is there any way to turn off the publishing of externalmethods to the web in Zope?
Using a proxy role on the calling Python Script worked. My guess is that a clever hacker could call the Python Script continually and then create a race condition that would permit him to call the External Method directly in a URL, thus passing the External Method his own malicious parameters.
That's why i suggested, in an earlier response, a URL test within the external method. Jonathan
Mark, Jonathan (Integic) wrote:
I will add the URL test. In addition, I will pass a long symettric 64 bit key to the external method as a parameter, and require the external method to confirm that the correct key was passed. Since only I have access to my file system and to my ZMI this is sufficient.
Excuse me for saying, but this is all slightly nuts. Is there some reason you're being so (overly) paranoid? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
"""Excuse me for saying, but this is all slightly nuts. Is there some reason you're being so (overly) paranoid? Chris""" 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.
Mark, Jonathan (Integic) wrote:
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.
Why do you object philosophically to them? DTML is nasty, I would agree, but I've yet to find a web templating language that works as well in practice as ZPT in terms of separating design and presentation (especially when combined with Zope 3 views; and possibly moving in the direction of something like Pushpage by Tres). I guess it comes down to taste. I found Cheetah horrendously ugly, aesthetically speaking.
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.
I'm not sure if this is constructive, but it seems to me that you are trying to use Zope in a way that, at best, people are actively moving away from, or at worst, it wasn't really designed to be used. In particular, it seems strange to me to want to have pyscripts that explicitly call Cheetah templates, and to make extensive use of external methods (why not just use products and filesystem code in custom objects that represent your data model?). Also note that if all you really need is a blog, there are probably existing solutions you could use and build on rather than have to create your own. In truth, you may be interested to learn more about Zope 3 and even grok. They are different ways of programming, but more "pythonic" and very powerful. I can recommend Philipp von Weitershausen's Zope 3 book (http://worldcookery.com) (disclaimer: I helped proof read it), if you want to learn something new and exciting.
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.
Eval sounds like a really nasty hack (isn't it always?). You'll probably find it hell to debug as well... I would assume it's possible to write some first-class object in Zope that could act similarly to DTML or ZPT objects but do the rendering using Cheetah, if you really want to use that. Martin -- View this message in context: http://www.nabble.com/Is-there-any-way-to-turn-off-the-publishing-of-externa... Sent from the Zope - General mailing list archive at Nabble.com.
Martin Aspeli wrote:
Pushpage by Tres). I guess it comes down to taste. I found Cheetah horrendously ugly, aesthetically speaking.
Martin, I'd be interested in your views on Twiddler :-)
Also note that if all you really need is a blog, there are probably existing solutions you could use and build on rather than have to create your own.
I actually think Zope 3 could do with a decent blog/forum tool, so there is merit in tacking this project the right way..
Eval sounds like a really nasty hack (isn't it always?).
Except in a very few niche uses, yes... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Mark, Jonathan (Integic) wrote:
I don't know Zope well,
No offence, but that much is apparent ;-)
excellent Squishdot product for three years at Goodbyejim.com. Chris has moved on to other Zope activities and has not upgraded Squishdot since 2001.
I still use Squishdot heavilly. I committed a whole load of changes at the back end of last year. They're in svn on SourceForge if you want to take a look...
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.
Good luck ;-)
As many of us know, BDFL Guido doesn't seem to think much of Zope.
I don't think Guido cares much one way or another...
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.
Then why are you looking at Zope 2. Zope 3 is where you should be looking...
I thus object philosophically to ZPT and DTML and hope to avoid
Offence intended, you're nuts ;-) You need some templating system, you've settled on Chettah by the look of it (god knows why, it's horrific from what I remember of it) but it's still a templating system so I have no idea how you can object "philosophically" to ZPT and not Cheetah...
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.
If you're releasing a product, why are you talking about external methods? A Zope 2 product should have no reliance on external methods...
My attempt to use Chris's Twiddler templating tool as an external method
Yup, definitely nuts. I go to the trouble of providing a Zope 2 layer for Twiddler and you don't even try to use it... nice ;-)
instead of Cheetah ran into a problem which I am sure was my fault,
Did you ask on this or the Twiddler mailing list?
Wisdom. Twiddler and Cheetah appear equally wise, so PLR said go with Cheetah.
Now that I find offensive. If you're using Cheetah, you might as well have stuck with ZPT.
name) to be visible in Python scripts and folder properties.
That's very old school. You need to learn from Zope 2, no keep bashing away at it. My recommendation would be to buy Philipp's Zope 3 book and read it from cover to cover before you start work...
External methods should be only a wrapper to Cheetah and
You should not be using external methods at all...
My paranoid nature is due to a fear of creating my own product and finding out that I have left a security hole.
Then you should read up on Zope 2 security and write a Zope 2 product, rather than hacking away blindly with external methods...
By using Eval in my external method
If you ever ever ever use eval, then you definitely are nuts ;-) bemusedly, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
I wish to thank Chris for his helpful comments. I accept them in the playful spirit in which they were offered. This sort of feedback is essential to people who are learning. LESSON #1: If it looks as if a product is no longer maintained then ask the maintainer of the product if he has any uncommitted changes in his version control system. LESSON #2: If you want to produce a new product/component, learn Zope 3 and use that for the new work, unless Zope 2 compatibility is for some reason required. LESSON #3: "A Zope 2 product should have no reliance on external methods..." LESSON #4: If a competent programmer provides Zope bindings then make a reasonable effort to get them to work instead of giving up and using external methods. LESSON #5: """My recommendation would be to buy Philipp's Zope 3 book and read it from cover to cover before you start work...""" LESSON #6: """If you ever ever ever use eval, then you definitely are nuts ;-)"""
Mark, Jonathan (Integic) wrote:
LESSON #1: If it looks as if a product is no longer maintained then ask the maintainer of the product if he has any uncommitted changes in his version control system.
They're not uncommitted, they're in a public subversion repository thats' advertised on the project's pages on sourceforge which is linked to from squishdot.org...
LESSON #2: If you want to produce a new product/component, learn Zope 3 and use that for the new work, unless Zope 2 compatibility is for some reason required.
Right.
LESSON #4: If a competent programmer provides Zope bindings then make a reasonable effort to get them to work instead of giving up and using external methods.
You install Twiddler, you follow the install instructions in twiddler/zope2/readme.txt and then you have Twiddler as an option in your ZMI add menu.
LESSON #5: """My recommendation would be to buy Philipp's Zope 3 book and read it from cover to cover before you start work..."""
I can't stress this one enough either, many thanks again to Philipp for doing the one thing that Zope has always needed :-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Mark, Jonathan (Integic) wrote:
Using a proxy role on the calling Python Script worked. My guess is that a clever hacker could call the Python Script continually and then create a race condition that would permit him to call the External Method
Why would calling a python script continuously set up a race condition?
However, for now Proxy is sufficient. Thanks.
If you can find a security hole, it'd be addressed pretty fast... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
----- Original Message ----- From: "Mark, Jonathan (Integic)" <jonathan.mark@integic-hc.com> To: <zope@zope.org> Sent: Friday, January 26, 2007 10:29 AM Subject: [Zope] Is there any way to turn off the publishing of externalmethods to the web in Zope?
I have an external method which uses eval(). I would like to prevent anyone from calling this method from inside a URL, e.g., myzopesite/myexternalmethod?myvar=deletemyfiles()
Rather, I wish for only Zope objects such as Python Scripts to be able to call this external method. Is there any way to turn off the publishing of external methods to the web in Zope?
In your external method you could put something like: if string.find(self.REQUEST['ACTUAL_URL'], 'ExtMethodName') != -1: return self.REQUEST.RESPONSE.redirect('BadUserURL') hth Jonathan (another one)
Jonathan wrote:
if string.find(self.REQUEST['ACTUAL_URL'], 'ExtMethodName') != -1: return self.REQUEST.RESPONSE.redirect('BadUserURL')
This is a pretty weak and silly way of going about this... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Mark, Jonathan (Integic) wrote at 2007-1-26 10:29 -0500:
I have an external method which uses eval(). I would like to prevent anyone from calling this method from inside a URL, e.g., myzopesite/myexternalmethod?myvar=deletemyfiles()
Rather, I wish for only Zope objects such as Python Scripts to be able to call this external method. Is there any way to turn off the publishing of external methods to the web in Zope?
When you do not want that a object is called from the Web, you have too options: give it a non 'None' 'index_hmtl' (then this 'index_html' is called and can tell that this object must not be called directly) or give it an empty '__doc__'. The ZMI does not give you a way to do this, but you can do it in an interactive Python interpreter accessing your storage directly (under *nix: "bin/zopectl debug"). -- Dieter
participants (6)
-
Andreas Jung -
Chris Withers -
Dieter Maurer -
Jonathan -
Mark, Jonathan (Integic) -
Martin Aspeli