[Twisted-Python] pb.Copyable, round trip objects, and untrusted clients
radix at twistedmatrix.com
Fri May 21 00:52:55 EDT 2004
David Ripton wrote:
> On 2004.05.20 13:07:06 +0000, Christopher Armstrong wrote:
>>Well, your example didn't look like it had much use for using
>>particularly complex state going both ways. Maybe you can explain this
>>game-choosing process in a bit more detail? Without knowing any more,
>>letting the user choose which game he wants to play sounds like it
>>shouldn't be more complex than the server giving the client a list of
>>strings of game-names (like "Bob's l33t Server") and the client sending
>>back "Bob's l33t Server" in a request later on.
> The full game has much more complex state, which I will resist spelling
> out in detail. I was just trying to show a minimal example.
> Yes, that particular event would only really require sending a list of
> dicts or tuples, with each dict or tuple holding the ~6 attributes of
> a single game that need to be displayed in a table, from server to
> client. And then sending just the name or id of the one game that
> the user wants to join back to the server. (Another event would send a
> different subset of the game state.)
> But there is a (small) code size cost to pass just the attributes of
> the Game class that are needed for that GUI display. Passing the
> whole Game class (censored in a global rather than event-specific way)
> is simpler. And if I decide to add another column to that table,
> passing the whole object probably doesn't require a change to the
> remote call arguments, while passing the minimal bits does. And it just
> feels like better OO design to pass a whole object rather than ripping
> out bits and pieces of it.
Ok, I'm going to debate this assumption of yours. It seems you're
complaining about something that is barely a problem: let's talk about
code size. Here's an example of how stuff could work.
In the client:
def _cbGotGames(self, games):
# games is a list of complex objects, or whatever
print "games are", games
print "which one?"
def _cbChosenGame(self, game):
#here's what you think saves a lot of code space:
#as opposed to
Hmm, I count a single extra method call there. That doesn't seem like a
whole lot to me. :-) This is not worth getting worked up over.
Unfortunately, the Python community has somehow gotten into an obsession
with syntax, and is trying to reduce tiny amounts of extra syntax at all
costs.... but that's a rant for somewhere other than twisted-python.
> None of which matters much, if passing just dicts and strings and ints
> is secure, and passing copies of complex objects is not. (This seems to
> happen in every "distributed object system" I try. Basic RPC works
> [except in Java RMI, which appears to be an April Fool's joke];
> anything more complex works for "Hello World" then falls over in
There's certainly applications using Copyable and Cacheable in
production; I'm not sure what exactly you're talking about.
I'll wait until you respond to this email before going over the points
in the second section of your email.
>>IOW, the poster who said that your second and third points are basically
>>the same is correct; the API you're designing needs to be looked at
>>specifically to see the optimal secure/easy solution.
> Upon further review, I'm back to throwing minimal action objects both
> ways, eschewing Copyable and Cacheable completely in favor of manual
> solutions involving dicts and lists of strings and ints. Which is
> where I was a couple of weeks ago. The grass is always greener...
> The security issues in Copyable / Cacheable should knock me off this
> particular fence for long enough to have enough code written that I'm
> unwilling to climb back up.
Well, I'm defending my point in the name of sane, easy to implement
design, and not primarily security. I'm not really sure what big
security issues you're complaining about here. I think you're largely
overreacting; Copyable and Cacheable are certainly useful, usable
functionality. Of course, things aren't perfect, but we admit this with
the newpb project. We are trying to solve all of the problems with the
current PB there, especially security related. OTOH, I don't think
you've pointed out any real problems with it. It mostly seems to be
based on weird desires, to me. In fact, let me go back to your original
> Obviously, the client should only be able to change the server's
> game state via a well-defined error-checked interface. Also fairly
> straightforward, though error-prone since you need to forsee and
> test against every way to cheat.
> There's a third hole to plug, which is passing an object from the server
> to the client as an argument of a client-side remote_* method, and later
> getting it back as an argument to a server-side perspective_* method.
> (e.g. the server passes the client a list of games in progress, and
> later the client passes back the game it wants to join.) If the client
> changes the object before passing it back, it might trick the server
> into doing the wrong thing with it.
See, what it seems like you're saying here is "I want the client to be
able to send me data that I don't care about and that it shouldn't be
able to have control to change in the first place, but then I want to do
extra work on the server to throw that data out". I should have made
this point earlier, but I was rather tired when I last posted to this
thread :). Anyway, that's what I'm hearing, and it doesn't really make
sense to me.
Twisted | Christopher Armstrong: International Man of Twistery
Radix | Release Manager, Twisted Project
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20040521/513cb3e0/attachment.pgp
More information about the Twisted-Python