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

[David Bolen]

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