unpythonic use of property()?
J Kenneth King
james at agentultra.com
Wed Apr 22 19:44:38 CEST 2009
Luis Zarrabeitia <kyrie at 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
>> 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
> 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.
More information about the Python-list