Re: [Twisted-Python] How to determine whether transport.write() succeed?
On Mar 31, 2013, at 6:09 PM, Todong Ma gbstac...@gmail.com wrote: I wrote a simple client and server to get system information (e.g. cpu, memory, etc.) Client send 'cpu' to the server, then server will return cpu's information to client. Now client send multiple commands to server one time, e.g. cpu, memory, database, hard disk. But sometimes server couldn't receive some type information (e.g. cpu, database), and the missed information type is not fixed every time. So I want client to check whether ITransport.write() sends message to server successfully. If failed, client will resend the message to server. It's a good thing that write() doesn't convey information about send() succeeding so you can't trust it :). You can't rely on send() succeeding to convey this information: send() can succeed but all that means is that data moved from your application into your kernel. What you want to do is to have an application-level acknowledgement of the data that was sent. AMP will provide this for you automatically; when the Deferred returned by callRemote fires, the other end has received and acknowledged the information. -glyph ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
[Twisted-Python] twisted.cred interface deficiences
The twisted.cred.IUsernamePassword interface declares: * IUsernamePassword.username - The username associated with these credentials. * IUsernamePassword.password - The password associated with these credentials. * IUsernamePassword.checkPassword(password) - Validate these credentials against the correct password. The issue is that the interface (according to exarkun) allows you to implement checkPassword() to do things other than the obvious password == self.password. Now, this is an issue because Twisted then explicitly supports (again, according to exarkun) two different uses of this interface by the credentials checker: * Call the checkPassword() method, passing it the correct password * Just take the password out and do whatever you want with it (which is necessary in any secure system) Now, imagine I write a version of checkPassword() in a library which does something security-centric (what would this be? shouldn't it be part of the checker?), assuming that it'll be used by a credentials checker which calls checkPassword(). Except... then, a library user uses it with a credentials checker which checks the password itself. Now they're skipping over my security-centric code! So I have to tell my library users that they have to use my library with a credentials checker which makes sure to call checkPassword(), not just one which accepts the correct interface. IUsernamePassword's docstring claims that the stored password must be reversible to plaintext to be compared with the password, which implies that taking the password out and doing other things is incorrect, unlike what exarkun suggests. In this case, exposing password in the interface makes little sense. In addition, twisted.cred.checkers.FilePasswordDB apparently ignores this docstring entirely already (http://twistedmatrix.com/trac/browser/tags/releases/twisted-12.3.0/twisted/cred/checkers.py#L238). I propose that IUsernamePassword should be split into at least two interfaces: * IUsernamePassword, with only username and password, no methods, which allows password to be used in any way * Another interface, which only defines username and checkPassword() - possibly just a rename of IUsernameHashedPassword, which declares a similar interface However, this has the issue that any credential checker which can use the second interface would also be able to use an IUsernamePassword here if there were an adapter between the two, but support for this would have to go into every credential checker which supports the second interface at present. Maybe the Portal could automatically search for adapters if it can't find a direct match? Thanks, Cameron ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] twisted.cred interface deficiences
Why does IUsernameHashedPassword have to be renamed? It sounds like it's the appropriate thing already. On Mon, Apr 1, 2013 at 10:55 PM, Shell cam.t...@gmail.com wrote: The twisted.cred.IUsernamePassword interface declares: * IUsernamePassword.username - The username associated with these credentials. * IUsernamePassword.password - The password associated with these credentials. * IUsernamePassword.checkPassword(password) - Validate these credentials against the correct password. The issue is that the interface (according to exarkun) allows you to implement checkPassword() to do things other than the obvious password == self.password. Now, this is an issue because Twisted then explicitly supports (again, according to exarkun) two different uses of this interface by the credentials checker: * Call the checkPassword() method, passing it the correct password * Just take the password out and do whatever you want with it (which is necessary in any secure system) Now, imagine I write a version of checkPassword() in a library which does something security-centric (what would this be? shouldn't it be part of the checker?), assuming that it'll be used by a credentials checker which calls checkPassword(). Except... then, a library user uses it with a credentials checker which checks the password itself. Now they're skipping over my security-centric code! So I have to tell my library users that they have to use my library with a credentials checker which makes sure to call checkPassword(), not just one which accepts the correct interface. IUsernamePassword's docstring claims that the stored password must be reversible to plaintext to be compared with the password, which implies that taking the password out and doing other things is incorrect, unlike what exarkun suggests. In this case, exposing password in the interface makes little sense. In addition, twisted.cred.checkers.FilePasswordDB apparently ignores this docstring entirely already ( http://twistedmatrix.com/trac/browser/tags/releases/twisted-12.3.0/twisted/cred/checkers.py#L238 ). I propose that IUsernamePassword should be split into at least two interfaces: * IUsernamePassword, with only username and password, no methods, which allows password to be used in any way * Another interface, which only defines username and checkPassword() - possibly just a rename of IUsernameHashedPassword, which declares a similar interface However, this has the issue that any credential checker which can use the second interface would also be able to use an IUsernamePassword here if there were an adapter between the two, but support for this would have to go into every credential checker which supports the second interface at present. Maybe the Portal could automatically search for adapters if it can't find a direct match? Thanks, Cameron ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python -- cheers lvh ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
