[Twisted-Python] Re: More on PB Copyable Errors

Justin Johnson justinjohnson at gmail.com
Thu Dec 30 10:57:49 EST 2004


Option 1 is also most like the way things work today for sending
anything that isn't an error.  The only reason CopyableFailure exists
is because you HAVE to send a failure.  Whether it is
jelly/unjellyable or not, the other end must be informed of errors. 
But as soon as a developer decides to make their errors copyable, they
have in effect agreed that they are responsible for testing the
unjellying on the other end.


On Thu, 30 Dec 2004 09:48:17 -0600, Justin Johnson
<justinjohnson at gmail.com> wrote:
> 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
> following happens:
> 
> 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
> them.
>   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.
> 
> -Justin
> 
> 
> 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
> > instance).
> >
> > 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
> > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
> >
>




More information about the Twisted-Python mailing list