Re: [Zope-dev] xml-rpc changes between 2.7.0 and 2.7.3 ??
Hi, Am Di, den 12.10.2004 schrieb Alan Milligan um 0:16: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I had a client that used to work on 2.7.0, and now doesn't on 2.7.3. The problem would appear to be that it's not substituting the xmlrpc.Response class for a GET request on a text/xml content type and therefore just delegating to the str() function instead of wrapping it in the xml-rpc xml response tags. I'm a little confused about this, as this only appears to happen in HTTPRequest::processInputs which didn't seem to be invoked for my xml-rpc call anyway ... tcpdump follows for the sceptics ... j.. 08:05:04.901469 IP mistress.balclutha.org.34257 mistress.balclutha.org.zope: P 1:456(455) ack 1 win 32767 nop,nop,timestamp 225097763 225097723 [EMAIL PROTECTED]@.)..W.x... j..GET /last-bastion.net/junk/rpm/RPC2/$RHN/mail/listPackages/1 HTTP/1.1 Host: localhost:8080 Accept-Encoding: identity x-client-version: 1 x-transport-info: Extended Capabilities Transport (C) Red Hat, Inc (version 1.40) x-up2date-version: user-agent: rhn.rpclib.py/$Revision: 1.40 $ x-rhn-transport-capability: follow-redirects=1 x-rhn-auth-channels: ['mail', '1'] content-type: text/xml x-info: RPC Processor (C) Red Hat, Inc (version 1.44) Your log is a bit confusing maybe you better use tcpflow for dumping. But what is clearly seen is the GET request. I wonder how this ever was supposed to work since XML-RPC requires an entidy body for the message (which is in XML). You can compare with RFC2616 - there is no entidy body in GET. Your client needs to use POST. I suspect then it should work. Regards Tino ___ 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: Re: [Zope-dev] xml-rpc changes between 2.7.0 and 2.7.3= ??
Heh, Yes - would you like to lobby RedHat to change their up2date client?? I think the reason they've done this is because it's much more efficient. Not only do they not have to read the body, they don't have to parse it. Also, xml-rpc is totally screwed because it doesn't have a file type, and the normal binary limitation is 8192 bytes of parsable data between two tags :( Alan Hi, Am Di, den 12.10.2004 schrieb Alan Milligan um 0:16: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I had a client that used to work on 2.7.0, and now doesn't on 2.7.3. The problem would appear to be that it's not substituting the xmlrpc.Response class for a GET request on a text/xml content type and therefore just delegating to the str() function instead of wrapping it in the xml-rpc xml response tags. I'm a little confused about this, as this only appears to happen in HTTPRequest::processInputs which didn't seem to be invoked for my xml-rpc call anyway ... tcpdump follows for the sceptics ... j.. 08:05:04.901469 IP mistress.balclutha.org.34257 mistress.balclutha.org.zope: P 1:456(455) ack 1 win 32767 nop,nop,timestamp 225097763 225097723 [EMAIL PROTECTED]@.)..W.x... j..GET /last-bastion.net/junk/rpm/RPC2/$RHN/mail/listPackages/1 HTTP/1.1 Host: localhost:8080 Accept-Encoding: identity x-client-version: 1 x-transport-info: Extended Capabilities Transport (C) Red Hat, Inc (version 1.40) x-up2date-version: user-agent: rhn.rpclib.py/$Revision: 1.40 $ x-rhn-transport-capability: follow-redirects=1 x-rhn-auth-channels: ['mail', '1'] content-type: text/xml x-info: RPC Processor (C) Red Hat, Inc (version 1.44) Your log is a bit confusing maybe you better use tcpflow for dumping. But what is clearly seen is the GET request. I wonder how this ever was supposed to work since XML-RPC requires an entidy body for the message (which is in XML). You can compare with RFC2616 - there is no entidy body in GET. Your client needs to use POST. I suspect then it should work. Regards Tino ___ 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] Possible Windows Service improvements.
Ressurecting a bit of an old thread: From: Chris McDonough [mailto:[EMAIL PROTECTED] Sent: Wednesday, 4 August 2004 11:19 PM Subject: Re: [Zope-dev] Possible Windows Service improvements. ... I'm a Windows signal idiot. I was too. I think I understand them a little better now after having played with both the signal module, and the win32 specific functions. Is there a way that we can make the Zope process capture Windows signals and when the Windows equivalent of SIGTERM is sent to the process to shut it down cleanly? This is how it works on UNIX, but we circumvent trying to listen for signals on Windows entirely at startup. There are all sorts of hooks for clean shutdown now that we can coopt if we can make the process capture a signal. I've uploaded a patch to http://collector.zope.org/Zope/1527. I'd appreciate any comments - specifically about if I have hooked the appropriate place. My first reaction was that the correct hooks were in SignalHandler.py and Signals.py - however, Windows signals really aren't suitable for hooking there - only SIGINT is supported. Trying to twist code into pretending signals on Windows worked like Linux ended up with a bit of a mess. Hacking Lifetime.py was the cleanest solution. Note that the UNIX environment has a lot of additional niceties due to responses to signals (like logfile rotation) that Windows doesn't now, which tends to have the effect of relegating Windows to a second-class platform on which to run a production Zope instance. I guess the correct way to do that gets back to the other issue this thread raised - cross-platform startup/error reporting and command handling. I fear that will take a little longer to implement. I hope to break this up into 2 tasks: * Give windows reliable shutdown behaviour now. * Try and develop a basis for reliable cross-platform parent/child notification and control. I think the first would allow us to gracefully shutdown services - at the moment the child process is immediately terminated! The second would give us better startup and error recovery, but that seems less important to me. I hope to submit a patch for the service code shortly. Mark ___ 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: Bad interaction between Zope 2.7.3 and CMF 1.4
Dieter Maurer wrote:
Tres Seaver wrote at 2004-10-9 12:04 -0400:
Stefan H. Holek wrote:
While testing a large-ish customer project under Zope 2.7.3 we found that
when an object with setDefaultAccess('deny') is used as the context for
a PythonScript, the script can no longer aquire tools from the portal
root.
*By definition*, anybody who has declared 'setDefaultAccess('deny')
*wants* the behavior you describe: that declaration says, unless I
give you explicit permission for using a name, refuse.
I do *NOT* think that this is the intended semantics of
setDefaultAccess('deny').
In my view, setDefaultAccess(XXX) should only affect objects
that do not have security declarations themselves.
Acquired tools have security declarations -- they should not be
affected by setDefaultAccess.
If Plone has classes which make such assertions, then either the authors
*meant* them, or they need to be removed. This is (literally) the same
thing as declaring '__allow_access_to_unprotected_subobjects__ = 0' in
your class.
With this name, it becomes even clearer:
Acquires tools are neither unprotected nor subobjects.
Hmm, I tried writing a test te verify that my change (after 2.7.2) had
modified the security policy's behavior. Here is the test, which I
expected to pass on the head of the 2.7 branch, but fail on 2.7.2:
--- lib/python/AccessControl/tests/testZopeSecurityPolicy.py27 Jan
2004 19:22:36 - 1.6.2.6
+++ lib/python/AccessControl/tests/testZopeSecurityPolicy.py12 Oct
2004 17:15:05 -
@@ -336,6 +336,16 @@
else:
self.fail('Policy accepted bad __roles__')
+def test_no_acquisition_through_paranoid(self):
+
+# Check that acquisition through a paranoid object is not allowed.
+app = App()
+app.wanted = UnprotectedSimpleItem()
+app.enabling = UnprotectedSimpleItem()
+app.blocking = RestrictedSimpleItem()
+self.assertPolicyAllows(app.enabling, 'wanted')
+self.assertPolicyDenies(app.blocking, 'wanted')
+
def test_suite():
return unittest.makeSuite(ZopeSecurityPolicyTests)
However, it passes for both. Anyone care to speculate why?
Tres.
--
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation Zope Dealers http://www.zope.com
___
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: Bad interaction between Zope 2.7.3 and CMF 1.4
Tres Seaver wrote:
Dieter Maurer wrote:
Tres Seaver wrote at 2004-10-9 12:04 -0400:
Stefan H. Holek wrote:
While testing a large-ish customer project under Zope 2.7.3 we found
that
when an object with setDefaultAccess('deny') is used as the context for
a PythonScript, the script can no longer aquire tools from the portal
root.
*By definition*, anybody who has declared 'setDefaultAccess('deny')
*wants* the behavior you describe: that declaration says, unless I
give you explicit permission for using a name, refuse.
I do *NOT* think that this is the intended semantics of
setDefaultAccess('deny').
In my view, setDefaultAccess(XXX) should only affect objects
that do not have security declarations themselves.
Acquired tools have security declarations -- they should not be
affected by setDefaultAccess.
If Plone has classes which make such assertions, then either the
authors *meant* them, or they need to be removed. This is
(literally) the same thing as declaring
'__allow_access_to_unprotected_subobjects__ = 0' in your class.
With this name, it becomes even clearer:
Acquires tools are neither unprotected nor subobjects.
Hmm, I tried writing a test te verify that my change (after 2.7.2) had
modified the security policy's behavior. Here is the test, which I
expected to pass on the head of the 2.7 branch, but fail on 2.7.2:
--- lib/python/AccessControl/tests/testZopeSecurityPolicy.py27 Jan
2004 19:22:36 - 1.6.2.6
+++ lib/python/AccessControl/tests/testZopeSecurityPolicy.py12 Oct
2004 17:15:05 -
@@ -336,6 +336,16 @@
else:
self.fail('Policy accepted bad __roles__')
+def test_no_acquisition_through_paranoid(self):
+
+# Check that acquisition through a paranoid object is not
allowed.
+app = App()
+app.wanted = UnprotectedSimpleItem()
+app.enabling = UnprotectedSimpleItem()
+app.blocking = RestrictedSimpleItem()
+self.assertPolicyAllows(app.enabling, 'wanted')
+self.assertPolicyDenies(app.blocking, 'wanted')
+
def test_suite():
return unittest.makeSuite(ZopeSecurityPolicyTests)
However, it passes for both. Anyone care to speculate why?
Tres.
OK, so my change was specifically to 'guarded_getattr', so the test was
exercising the wrong thing. Note that this means that the old behaviour
of guarded_getattr was allowing objects to be returned which wouldn't be
validated (I think). Here is a test for 'guarded_getattr', which
*fails* both before and after my change:
--- lib/python/AccessControl/tests/testZopeGuards.py16 Jan 2004
21:04:54 - 1.1.4.3
+++ lib/python/AccessControl/tests/testZopeGuards.py12 Oct 2004
17:51:13 -
@@ -24,11 +24,14 @@
import AccessControl.SecurityManagement
from AccessControl.SimpleObjectPolicies import ContainerAssertions
from zExceptions import Unauthorized
+from Acquisition import Explicit
from AccessControl.ZopeGuards \
import guarded_getattr, get_dict_get, get_dict_pop, get_list_pop, \
get_iter, guarded_min, guarded_max, safe_builtins,
guarded_enumerate, \
guarded_sum, guarded_apply
+from testZopeSecurityPolicy \
+import App, UnprotectedSimpleItem, RestrictedSimpleItem
try:
__file__
except NameError:
@@ -112,6 +115,17 @@
self.assertEqual(values.args, (d, 'values'))
finally:
ContainerAssertions[_dict] = old
+
+def test_no_acquisition_through_paranoid(self):
+
+# Check that acquisition through a paranoid object is not allowed.
+app = App()
+app.wanted = UnprotectedSimpleItem()
+app.enabling = UnprotectedSimpleItem()
+app.blocking = RestrictedSimpleItem()
+ok = self.guarded_getattr(app.enabling, 'wanted')
+self.assertRaises(Unauthorized,
+ self.guarded_getattr, app.blocking, 'wanted')
class TestGuardedGetattrC(TestGuardedGetattrPy):
Aargh!
Tres.
--
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation Zope Dealers http://www.zope.com
___
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] xml-rpc changes between 2.7.0 and 2.7.3 ??
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tino Wildenhain wrote:
|
|I had a client that used to work on 2.7.0, and now doesn't on 2.7.3.
|
|The problem would appear to be that it's not substituting the
|xmlrpc.Response class for a GET request on a text/xml content type and
|therefore just delegating to the str() function instead of wrapping it
|in the xml-rpc xml response tags.
|
| I wonder how this ever was supposed to work since
| XML-RPC requires an entidy body for the message (which is
| in XML). You can compare with RFC2616 - there is no
| entidy body in GET. Your client needs to use POST.
| I suspect then it should work.
|
Ok, I now more fully understand the subtlety of this explanation.
What happened here is that in cgi.py's FieldStorage class, since this is
a GET request, it completely ignores the CONTENT_TYPE environment and
sets the content-type header to x-www-form-urlencoded.
According to Dave Winer's spec at http://www.xmlrpc.com/spec, XML-RPC is
supposed to be HTTP-POST based, where this issue is fully resolved.
I have implemented this GET 'Extension' with this patch.
I appreciate that supporting 'unofficial' extensions to protocols is not
something we want to encourage, but is there any chance of getting this
patch into zope core (ever)?
Cheers, Alan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBbIWLCfroLk4EZpkRAlX3AKDI5Cdb6CUfdkqtSrEllfZeEGEnMwCdHJN0
78EIcOvXOD2H4imuI2NQOxw=
=H+yj
-END PGP SIGNATURE-
--- HTTPRequest.py 2004-10-13 11:22:32.212653472 +1000
+++ HTTPRequest.py.orig 2004-10-13 11:20:51.146017936 +1000
@@ -385,11 +385,9 @@
fs=FieldStorage(fp=fp,environ=environ,keep_blank_values=1)
if not hasattr(fs,'list') or fs.list is None:
# Hm, maybe it's an XML-RPC
-if ((fs.headers.has_key('content-type') and
- fs.headers['content-type'] == 'text/xml' and
- method == 'POST') or
- (environ.get('CONTENT_TYPE','') == 'text/xml' and
- method == 'GET')):
+if (fs.headers.has_key('content-type') and
+fs.headers['content-type'] == 'text/xml' and
+method == 'POST'):
# Ye haaa, XML-RPC!
global xmlrpc
if xmlrpc is None: import xmlrpc
___
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] xml-rpc changes between 2.7.0 and 2.7.3 ??
Hi, Am Mi, den 13.10.2004 schrieb Alan Milligan um 3:31: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tino Wildenhain wrote: | |I had a client that used to work on 2.7.0, and now doesn't on 2.7.3. | |The problem would appear to be that it's not substituting the |xmlrpc.Response class for a GET request on a text/xml content type and |therefore just delegating to the str() function instead of wrapping it |in the xml-rpc xml response tags. | | I wonder how this ever was supposed to work since | XML-RPC requires an entidy body for the message (which is | in XML). You can compare with RFC2616 - there is no | entidy body in GET. Your client needs to use POST. | I suspect then it should work. | Ok, I now more fully understand the subtlety of this explanation. What happened here is that in cgi.py's FieldStorage class, since this is a GET request, it completely ignores the CONTENT_TYPE environment and sets the content-type header to x-www-form-urlencoded. According to Dave Winer's spec at http://www.xmlrpc.com/spec, XML-RPC is supposed to be HTTP-POST based, where this issue is fully resolved. I have implemented this GET 'Extension' with this patch. I appreciate that supporting 'unofficial' extensions to protocols is not something we want to encourage, but is there any chance of getting this patch into zope core (ever)? -1 by me. Go and fix the broken client instead. I wonder who came to such a crazy idea to even think about sending a body with GET. Regards Tino ___ 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 )
