<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 2, 2013 at 6:04 PM, Glyph <span dir="ltr">&lt;<a href="mailto:glyph@twistedmatrix.com" target="_blank">glyph@twistedmatrix.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im"><br><div><div>On Apr 1, 2013, at 2:34 PM, Shell &lt;<a href="mailto:cam.turn@gmail.com" target="_blank">cam.turn@gmail.com</a>&gt; wrote:</div>
<br><blockquote type="cite"><blockquote type="cite" style="font-family:Monaco;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<blockquote type="cite">I propose that IUsernamePassword should be split into at least two<br>interfaces:<br><br>* IUsernamePassword, with only username and password, no methods,<br>which allows password to be used in any way<br>
* Another interface, which only defines username and checkPassword() -<br>possibly just a rename of IUsernameHashedPassword, which declares a<br>similar interface<br><br>However, this has the issue that any credential checker which can use<br>
the second interface would also be able to use an IUsernamePassword<br>here if there were an adapter between the two, but support for this<br>would have to go into every credential checker which supports the<br>second interface at present. Maybe the Portal could automatically<br>
search for adapters if it can&#39;t find a direct match?<br></blockquote></blockquote></blockquote></div><br></div><div>These don&#39;t sound like bad ideas, but I think that if you&#39;re going to try to fix cred&#39;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.</div>
<div><br></div><div>A better use of energy would be directed at getting a generic SASL credentials implementation; in other words, fixing this fairly ancient ticket: &lt;<a href="https://twistedmatrix.com/trac/ticket/2015" target="_blank">https://twistedmatrix.com/trac/ticket/2015</a>&gt;.</div>
<div><br></div></div></blockquote><div><br></div><div style>For what it&#39;s worth, I worked on this back when, and while I don&#39;t have time to work on it right now (and probably won&#39;t for at least a couple of weeks), I&#39;m happy to answer questions, if anybody has them.</div>
<div style><br></div><div style>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.</div><div style><br></div>
<div style>My recollection was that integrating the results of that with specific protocols (and possibly with Cred using a &quot;higher level&quot; interface) would happen on a subsequent ticket, which is probably a good idea.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>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.</div>
<div><br></div><div>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&#39;t break anything.</div><span class="HOEnZb"><font color="#888888"><div>
<br></div><div>-glyph</div></font></span></div><br></blockquote><div><br></div><div> </div></div>--<div>Kevin Horn</div>
</div></div>