Luis Zarrabeitia <ky...@uh.cu> writes: > On Monday 20 April 2009 11:29:19 am J Kenneth King wrote: >> Changing the ID value would break things on the server, so I >> wanted to write the interface class to respect those conventions. > > Then, take this opportunity fix the server and prevent it from breaking once > you change the ID, because:
Unfortunately it's not my server to fix. I can suggest a patch, but that's it. > >> I'm well aware that if a developer really wanted to, they could get >> around it no matter what I did, but I figure that if I at least make >> it really difficult it will be obvious that they're really going into >> dangerous territory. > > you will have to do it anyway. > > I think it's great, for you, that the language you are using makes it so > extremely easy to bypass almost any access restriction that you may put in > the data sent to your clients. That means that you won't be overconfident, > that you are forced to make sound decisions from the beginning, and that you > won't be trusting that your clients will be well behaved (even with very > strong enforcement of data hiding, a malicious client could forge the > connection). > > Then, when the server is safe from user data, by all means go and make sure > that the clients (and even the server!) will complain as loudly as possible > if they want to break encapsulation. Well, really all I'm doing is writing a light framework around xmlrpclib. The design allows me to keep this kind of exception highly localized, so its not really a huge practical issue. The problem I had was that I found two approaches to the same problem that appeared to be pedantic in difference. However, you are right of course -- logically the server should protect against this vulnerability itself instead of the implementation using my framework. -- http://mail.python.org/mailman/listinfo/python-list