Thanks for the reply. 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? On 29 Dec 2004 14:15:57 -0500, David Bolen <db3l@fitlinxx.com> wrote:
Justin Johnson <justinjohnson@gmail.com> writes:
Attached is a patch with modifications to pb.py and jelly.py. With the patch applied, CopyableFailure.getStateToCopy first checks to see if the actual exception instance's class has an unjellyable registered so it can be unjellied on the other side. If it does, the actual exception instance is passed back as failure.value. Otherwise a string representation is passed back as it is today.
I think the one big risk with this approach is that I'm not sure a sender can ever know accurately whether a recipient will be able to unjelly a particular instance. In your case, you're assuming the two sides are symmetrical and have imported the same definitions, but that need not be the case. At least in general, it's certainly possible for the transmitting side to not have the unjellier registered (if it never expects to receive such objects back, for example). Or conversely, the sender may have an unjellier registered but the recipient won't. In this latter case you'd get an exception on the remote side which sending the string would have avoided.
One alternative approach to handle this is to transmit both the string and instance representation, and then let the decoding side trap any unjellier security exceptions and fall back to the string representation. The big question of course is whether such a fallback should be automatic, silent, etc..
Another option would be to provide some sort of configurability (perhaps something along the lines of how unsafe traceback support is handled) so an application could make the choice of what mode to operate in, either string names, or full instances (and the latter just has to have unjelliers registered just as for any other remotes).
I'm sort of in the same state you are in, in that for me the simplest approach is just transmit the instance because my two sides are in fact symmetric. So the short internal change to local source works fine for me too. But I think that any general addition to the twisted base needs to take the more general proposition (and issues) into account.
-- David
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python