Edit AllPages

Assuming you’re vending an NSProtocolChecker for a protocol that doesn’t have the -privateMethod method included, and it’s stored in the remoteObject variable on the client side, is there anything that prevents the client program from evading the NSProtocolChecker simply by saying:

remoteObject target] privateMethod];

instead of:

[remoteObject privateMethod];

As far as I can tell, in the first case the -[[[NSProtocolChecker target] method never reaches -[NSProtocolChecker forwardInvocation:] and so is never subjected to the protocol check. Then the DistributedObjects system creates a proxy for the real object, bypassing the NSProtocolChecker.

Am I overlooking something? Is there some magic that takes place here?

I suggest simply trying it and seeing what it does. I’d guess that there’s something in place that prevents this bypass from working, but I don’t know what it would be.

I’ll definitely do that before I start relying on it.

Check out -[NSObject replacementObjectForPortCoder:]. NSProtocolChecker may or may not be smart about its target method, but you can definitely implement replacementObjectForPortCoder: on the target class to avoid the problem.

That’s right, I forgot about that… so this won’t be nearly the problem it’d be otherwise. Thanks!