[Twisted-Python] Generally useful RFC2617
Currently in Twisted/sandbox/dreid/rfc2617.py (with unittests at test_rfc2617.py) there is an implementation of RFC 2617 HTTP Authentication: Basic and Digest based authentication. It is based on the implementations found in twisted.protocols.sip, mantissa.sip, and sine.sip. The goal was to pull the sip specific stuff from these implementations and make something that would be useful for other protocols such as HTTP and IMAP. A couple of points are unclear however. 1) Where to put it? In theory it should be in twisted core. I just don't know where, and didn't want to check it in there somewhere only to have developers with more pull than I have to disagree, itamar suggested t.py.digest, dash seemed to agree, other suggestions were t.cred.digest, but I just don't know. 2) IAuthorizer. rfc2617.IAuthorizer, and *.sip.IAuthorizer before it, strike me as a really poorly named interface. It's purpose is to create challenges, and decode the response into something that can be used to return an ICredentials. This seems like a more generally useful concept than just to HTTP Auth, but there isn't currently anything like it cred. (Note I'm aware of cred.authorizer but they are not even similar interfaces, which is part of the reason IAuthorizer is so poorly named.) Anyway, I'm just hoping someone will tell me where to put it other than "where the sun don't shine" because I think that's covered under *.sip -David
On Tue, Nov 01, 2005 at 09:57:53AM -0800, David Reid wrote:
Currently in Twisted/sandbox/dreid/rfc2617.py (with unittests at test_rfc2617.py) there is an implementation of RFC 2617 HTTP Authentication: Basic and Digest based authentication. [..]
1) Where to put it?
In theory it should be in twisted core. I just don't know where, and didn't want to check it in there somewhere only to have developers with more pull than I have to disagree, itamar suggested t.py.digest, dash seemed to agree, other suggestions were t.cred.digest, but I just don't know.
This appears to be implementing the server side. Correct? I've been working on implementing SASL for Jabber and started with the client side of SASL, with server side to follow later. I think we have similar concerns and might join efforts. SASL authentication is really a collection of different authentication methods in a common framework. Protocols like Jabber and IMAP define their own profiles for encoding and communicating the different steps. So I split my code in two parts: - for each mechanism a profile-agnostic implementation - a Jabber specific wrapper that decodes and encodes using Base64 and does the protocol side. The first should be usable for IMAP and other SASL using protocols as well, so we need to have a common location for this. To get back to your stuff, the SASL Digest-MD5 mechanism, as described in RFC 2831 is intended to be upward compatible with the md5-sess algorithm of HTTP/1.1 Digest Access Authentication, so there is overlap there. As far as I know Twisted Cred now only concerns itself with the server side of matching credentials to 'accounts', not with the interaction between entities, like SASL, so we need to find our stuff a nice home. -- Groetjes, ralphm
participants (2)
-
David Reid -
Ralph Meijer