Martijn Faassen writes:
I'm not sure what one could do to let DTML become a conceptually pure reporting language. Redesign it in some unspecified fashion. Offer an alternative that is as easy to use as DTML; people currently use DTML as it's quick and easy. PythonMethods are perhaps the solution there.
This leads on to a security-related, I think. DC staff have said in the past that Python code isn't stored in the database for security reasons. PythonMethods change this; someone who gets your manager password can create a Python method that makes a setuid copy of your shell or whatever. (Disclaimer: I haven't actually gotten around to trying out PythonMethods yet.) On the one hand, I can agree that I don't want the security of my system depending on Zope passwords that are sent using HTTP's insecure Basic Authentication. (What's the status of Digest Authentication these days, anyway?) That's bad. On the other hand, PythonMethods would make it much easier to push complicated logic out of DTML and into Python code. That's good. Question: Is there a way we can reconcile these two conflicting drives? If some solution can be found, then maybe PythonMethods could be added to the products that come with basic Zope. Suggestions? 1) Perhaps PythonMethods could be enabled or disabled when you install Zope; if people are going to be using Zope over insecure links, and shouldn't be using PythonMethods, don't install them.. 2) Perhaps they could use the rexec module or Zope's existing sandbox to run their code (but would the sandbox limit their usefulness? -- maybe not, if you take the attitude that serious Python code should still be in a product or ExternalMethod). -- A.M. Kuchling http://starship.python.net/crew/amk/ None could break the Web, no wings of fire. / So twisted the cords, & so knotted / The meshes: twisted like to the human brain. -- William Blake