[Twisted-Python] Re: More on PB Copyable Errors
justinjohnson at gmail.com
Thu Dec 30 10:48:17 EST 2004
I agree. I did some testing to verify what you were saying. So this
is basically reiterating everything you just said, but just for
clarification for myself... in the current non-patched code the
When the server encounters an error while calling a method that was
invoked from a remote client, it will...
1) Wrap all subclasses of pb.Error in a pb.CopyableFailure, thus
replacing actual pb.Error instances with a string representation of
2) Return a new (non-wrapping) pb.CopyableFailure for all other
errors, thus including stack trace, etc.
When the server needs to send anything else back to the client, if it
is a subclass of flavors.Jellyable it sends it back. Otherwise it
raises InsecureJelly on the server side.
On the client side it will unjelly the thing sent across if it can
(i.e. if setUnjellyableForClass was called). Otherwise it raises an
InsecureJelly on the client side.
So it seems like these are our options:
1) If an error is Jellyable, send it and assume the client will either
unjelly it or deal with unjellying errors.
2) If an error is Jellyable, send it. If the client fails to unjelly
it, communicate back to the server who then sends a CopyableFailure
wrapping the original error.
3) If an error is Jellyable, send both it and a CopyableFailure
wrapping the original error. The client can then first try to unjelly
the error and fall back to the CopyableFailure that was passed along.
I vote for option 1. Options 2 and 3 seem somewhat hacky to me.
On 29 Dec 2004 21:31:17 -0500, David Bolen <db3l at fitlinxx.com> wrote:
> Justin Johnson <justinjohnson at gmail.com> writes:
> > In my testing it seemed that I would get an InsecureJelly error on the
> > sending side if I tried to send back an object that I hadn't called
> > pb.setUnjellyableForClass on the sending side for. In other words,
> > calling setUnjellyableForClass on the sending side was a way of saying
> > that it was okay to send over the wire, and also a way of registering
> > what class to use when unjellying it if it were received.
> > Is this not correct?
> I believe the only purpose of setUnjellyableForClass is to establish
> what to do for unjellying. While it does also impact the global
> security options (which do get checked during jellying) the way it
> stores type information in there is only matched during unjellying, at
> least in my experience (it adds permission for the type but not the
> I believe the only (typical) requirement to support jellying an object
> is that it be a class that is a jelly.Jellyable subclass (such as any
> of the remoteable flavors like Copyable, Referenceable, etc...). Nothing
> else should be needed on the server side.
> I just tried a quick tweak to your s/e/c.py modules so that s.py
> returned an instance of a dummy class defined in e.py instead of an
> error, and it seems to work fine even if the server side (s) hasn't
> issued the setUnjellyableForClass call. Without that call, the client
> will raise the error after receiving the object. And even if the
> server does issue that call, if the dummy class isn't inheriting from
> Copyable, the insecure error is generated on the transmitting side.
> It is, however, possible to insert additional types/classes/modules
> into the global security options independent of class inheritance from
> Jellyable. This is how all the basic Python types are handled, but it
> can be extended to support your own classes (although I had a problem
> with extension classes/types, since I originally tried to use this to
> support mxDateTime objects without modifying jelly).
> So for example, if I have my test class "MyObject" in e.py, and
> instead of setUnjellyableForClass, I use something like
> "jelly.globalSecurity.allowInstancesOf(MyObject)", then the object
> will still be successfully sent and received (providing the instance
> data can also be jellied).
> So after writing this, the fact that the security options could get
> used to permit an instance (that isn't of a subclass of Jellyable) to
> be encoded might mean that just verifying Jellyable (ala my last
> response to Christopher) is insufficient, at least technically.
> Perhaps the only true way to determine if something is jellyable is to
> try to jelly it (heck, that's probably more Pythonic anyway), and just
> handle an exception as a fallback to the string representation.
> -- David
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
More information about the Twisted-Python