[Zope-dev] Preventing scripts from being called directly
Hello, I am trying to prevent PythonScripts from being called directly TTW. Is there a better way of doing this than the following code being called at the very begining of the script? if script.getPhysicalPath() = context.REQUEST.PUBLISHED.getPhysicalPath(): raise UnAuthorisedOrSimilar Thanks, /dario -- -- --- Dario Lopez-Kästen, IT Systems Services Chalmers University of Tech. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Debian and Zope
Thaddeus H. Black wrote: Can you tell us who that maintainer is? Luca De Vitis [EMAIL PROTECTED]. Last known Zope activity: 4 Nov 2003. Hmmm, don't know him. Anyone else know him? Oh well, I guess we'll just have to wait for someone with the necessary Zope and Debian Zen to emerge :-/ cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Preventing scripts from being called directly
Dario Lopez-Kästen wrote: I am trying to prevent PythonScripts from being called directly TTW. Why? Is there a better way of doing this than the following code being called at the very begining of the script? if script.getPhysicalPath() = context.REQUEST.PUBLISHED.getPhysicalPath(): raise UnAuthorisedOrSimilar Make the scripts only viewable by Manager, and give whatever calls them that role by Proxy. Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Preventing scripts from being called directly
Chris Withers wrote: Dario Lopez-Kästen wrote: I am trying to prevent PythonScripts from being called directly TTW. Why? because the scripts i use in conjunction with SUF and that return person information are callable as http://server/acl_users/scriptname. And the SUF API demands that the scripts accept a parameter that then can easily be supplied in the url. If all this is done, then I can obtain info about users that way. Not good. Is there a better way of doing this than the following code being called at the very begining of the script? if script.getPhysicalPath() = context.REQUEST.PUBLISHED.getPhysicalPath(): raise UnAuthorisedOrSimilar Make the scripts only viewable by Manager, and give whatever calls them that role by Proxy. hm... right... that'd require even more customisation polocy of my Plone site than what is there now... I think i'll use the above code until I have time to fix the role/proxy assinging programatically. BTW, will SUF have support for FS-based scripts in the future? /dario -- -- --- Dario Lopez-Kästen, IT Systems Services Chalmers University of Tech. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Patch: let non-seekable streams be input for ZPublisher (updated)
Hello, Dieter Maurer wrote: Maybe, I have a much simpler solution: Something in ZServer makes all file fields seekable by delivering them through some temporary (either a StringIO or a temporary file). Maybe, you could do the same for your requests? Yes, I could. But trying to avoid it was the very reason I tried to patch HTTPRequest for. What you propose is what the HTTPServer does for instance. I have at least two objections: 1) For big requests (big means some hardcoded threshold) HTTPServer buffers the request on disk. Then ZPublisher creates a FieldStorage instance which will write the request once again to disk. And that also means the request is read from disk several times. That's a bit too much blocking disk I/O in a production webserver for my liking. And that's not counting retries; each retry will add another pair of blocking disk I/O in the current implementation. What I'm trying to do is: - avoid unneeded disk I/O in retries - make it possible that self.stdin in HTTPRequest can be non-seekable such that it doesn't have to be buffered on disk before FieldStorage is created (and does exactly that buffering). 2) I'm convinced that the one and only ZServer thread should do without any blocking (I/O) call (besides select() that is) and I want AJPServer also be an experiment to see if this improves performance. cheers, andreas ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Debian and Zope
Thaddeus H. Black wrote: This question regards the code in Zope's zpasswd.py. If you know zpasswd.py or are involved in Debian, please reply. Debian GNU/Linux 3.1 releases soon. The Debian Zope package (actually the Debian `zopectl' package) has what Debian calls a Release Critical Bug open against it [http://bugs.debian.org/251038]. Normally, Debian's Zope maintainer would handle such a bug, but the maintainer seems to be inactive this year, so it falls to me to fix it. This is okay. The maintainer's work in earlier years is appreciated. The trouble is, I do not use Zope myself, so I am fixing the bug with limited understanding of the potential consequences of the fix. The part of the Debian fix which affects your Zope source is in zpasswd.py. At present, a user can invoke zpasswd in either of two ways: (1) without command-line options, in which case zpasswd prompts the user on tty for username and password; or (2) with username and password supplied on the command line. How the user cannot presently invoke zpasswd is (3) with username supplied on the command line, so that zpasswd prompts the user on tty for a password only. The Zope installation procedure on Debian requires option (3). With (3), I can cleanly eliminate the Release Critical Bug now and prevent Zope from being dropped from Debian 3.1. Thus I am adding (3) to Debian Zope. Question, please. Does my addition create some subtle problem I should know about? If Zope were coded perfectly cleanly, then the addition of option (3) should create no problem; but you and I have both done enough coding to realize that old code can sometimes depend in strange ways on the odd behavior of even older code. With my small addition, zpasswd now correctly handles (3). Is this okay, or can you think of something specific it might break, something I might not have noticed? I have checked everything I know how to check, but I do not know Zope; you guys do. Regrettably, Zope's public SVN seems to be down as I write these words, so in the unlikely event that someone had already added option (3) to zpasswd.py, I would not know about it. I do understand and respect that, like any good free-software developers, you will probably all want me to update Debian Zope now to Zope's latest version! To this, I must plead that such an update far exceeds the limits of my Zope ignorance (also, it would violate Debian Project policy, which permits me minimally to fix a Release Critical Bug for an inactive maintainer but forbids me from unilaterally hijacking his Debian package). The matter at hand now is not how to include the latest Zope (it is not Debian's usual practice to include the very latest software in any event) but rather how to keep Zope in Debian at all. This is a good cause and I am pleased to help. I do not regularly subscribe to zope-dev, so please copy your reply to me and to [EMAIL PROTECTED] (the latter automatically attaches your reply to the relevant official Debian bug report, #251038). If there were no reply, this would be okay; I would just assume that my fix were as good as it seems to be, and would proceed accordingly. Please reply by 23 August. If any active Zope developer on this list also happens to be a registered Debian Developer, he is asked to step in and take charge of Debian bug #251038 from here: one can find my full zopectl/zope Debian patch attached to the Debian bug report. Otherwise, thank you for your attention in this matter. If you want my patch to zpasswd.py, here it is. You probably want to apply it to your own SVN Zope source. diff -u zope-2.6.4/zpasswd.py zope-2.6.4.new/zpasswd.py --- zope-2.6.4/zpasswd.py 2004-08-03 20:34:53.0 + +++ zope-2.6.4.new/zpasswd.py 2004-08-03 18:49:11.0 + @@ -87,6 +87,16 @@ import do; do.ch(ac_path, user, group) +def get_password(): +while 1: +password = getpass.getpass(Password: ) +verify = getpass.getpass(Verify password: ) +if verify == password: +return password +else: +password = verify = '' +print Password mismatch, please try again... + def main(argv): short_options = ':u:p:e:d:' @@ -150,7 +160,10 @@ # Verify that we got what we need if not username or not password: -raise CommandLineError +if username: +password = get_password() +else: +raise CommandLineError access_file.write(username + ':' + generate_passwd(password, encoding) + @@ -163,14 +176,7 @@ if username != '': break -while 1: -password = getpass.getpass(Password: ) -verify = getpass.getpass(Verify password: ) -if verify == password: -break -else: -password = verify = '' -
