Justin Johnson <justinjohnson@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