<div class="gmail_quote">On Fri, Jul 31, 2009 at 12:23 AM, Glyph Lefkowitz <span dir="ltr">&lt;<a href="mailto:glyph@twistedmatrix.com">glyph@twistedmatrix.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div class="im">On Fri, Jul 31, 2009 at 12:31 AM, Kevin Horn <span dir="ltr">&lt;<a href="mailto:kevin.horn@gmail.com" target="_blank">kevin.horn@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

the following classes:<br><br>twisted.cred.credentials.CramMD5Credentials<br>twisted.mail.imap4.PLAINCredentials<br>twisted.mail.imap4.LOGINCredentials<br><br>all seem to implement the same interface, yet there is no Interface defined for these objects.<br>


</blockquote></div><div><br>It would be great if there were such an interface.</div></div></blockquote><div><br>Seems pretty simple, since teh de facto interface is already there.  What should such an interface be called?  Where should it live?<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&quot;But Kevin&quot;, you might be thinking, &quot;They all implement twisted.cred.credentials.IUsernameHashedPassword or t.c.c.IUsernamePassword&quot;.  That&#39;s true, but they all have additional methods which make them useful for handling SASL authentication in various protocols.  And those methods aren&#39;t included in those interfaces.<br>


</blockquote></div><div><br>Aaah, SASL.  There has been <i>quite</i> a bit of discussion of this, which resulted in a branch that looked near completion but eventually stalled, here:  <a href="http://twistedmatrix.com/trac/ticket/2015" target="_blank">http://twistedmatrix.com/trac/ticket/2015</a><br>

<br>I don&#39;t think that unifying this interface would <i>necessarily</i> require the resolution of this ticket, but it would at least be useful to see where things have been.<br></div></div></blockquote><div><br>Great, I&#39;ll try to take a look at this.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

So, should there be an Interface which describes the interface that these objects implement?</blockquote></div><div><br>Sounds good to me, but then, I haven&#39;t done a lot of work with SASL. <br></div><div class="im"><div>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
And why are two of these in the IMAP package and the third in cred?  Why not in the same place?<br></blockquote></div><div> <br>LOGIN and PLAIN authentication methods were implemented specifically for IMAP, since as with all things IMAP it had special requirements.  The general idea of hashed passwords was around before that in cred, but as you can see in the changeset that introduced it — <a href="http://twistedmatrix.com/trac/changeset/8290" target="_blank">http://twistedmatrix.com/trac/changeset/8290</a> — something was apparently (and, I suspect, naughtily) expecting to call moreChallenges and setResponse on an IUsernameHashedPassword.<br>

<br></div></div></blockquote><div><br>LOGIN I can understand, since it&#39;s basically IMAP-specific, but it seems to me that PLAIN should be more general, since it&#39;s a SASL mechanism that&#39;s used (or at least can be used) in several protocols.<br>
<br>It might be worth pointing out though, that something very similar to the IMAP LOGIN mechanism is implemented in the Infotrope ACAP server (just about he only open source ACAP server out there...something I&#39;m trying to remedy...which is how I got interested in all this in the first place) so maybe LOGIN could be generalized as well.  Probably not necessary, though.<br>
<br>As for the changeset you referenced, it looks like the intent was to expand the IUsernameHashedPassword interface, which I&#39;m not sure is the right approach.  Of course I&#39;m not sure it&#39;s NOT the right approach, either.  Perhaps a new interface that inherits from IUsernameHashedPassword?<br>
<br>Kevin Horn<br><br><br></div></div>