On Apr 1, 2013, at 2:34 PM, Shell <cam.t...@gmail.com> wrote:
>>> 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?
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
deprecations.
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>.
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.
-glyph
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
