[Twisted-Python] twisted.cred interface deficiences
kevin.horn at gmail.com
Wed Apr 3 12:06:02 EDT 2013
On Tue, Apr 2, 2013 at 6:04 PM, Glyph <glyph at twistedmatrix.com> wrote:
> On Apr 1, 2013, at 2:34 PM, Shell <cam.turn at gmail.com> wrote:
> I propose that IUsernamePassword should be split into at least two
> * 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?
> These don't sound like bad ideas, but I think that if you're going to try
> to fix cred's built-in credentials, this is a pretty labor-intensive and
> not particularly rewarding path to go down. Further refining the sad
> username+password credential interface will provide only some internal
> factoring improvements to existing types of authentication, at the cost of
> retrofitting all of them; not to mention dealing with broad-spectrum
> A better use of energy would be directed at getting a generic SASL
> credentials implementation; in other words, fixing this fairly ancient
> ticket: <https://twistedmatrix.com/trac/ticket/2015>.
For what it's worth, I worked on this back when, and while I don't have
time to work on it right now (and probably won't for at least a couple of
weeks), I'm happy to answer questions, if anybody has them.
Mostly what needed to happen was to merge the code in the branch with the
code in trunk which had diverged somewhat, and create some documentation on
how to use them.
My recollection was that integrating the results of that with specific
protocols (and possibly with Cred using a "higher level" interface) would
happen on a subsequent ticket, which is probably a good idea.
> A well-implemented SASL credentials interface will address these issues,
> as well as allowing for proper challenge-response authentication, digest
> auth, external auth mechanisms like TLS, et cetera.
> Your idea about adapters is well taken though; having the portal do that
> when SASL-ified checkers are available seems reasonable, provided that it
> won't break anything.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Twisted-Python