pidgin: c842e713: Skip the X-GOOGLE-TOKEN mech (given us b...

[Evan Schoenberg]

On May 21, 2008, at 2:42 PM, Richard Laager wrote:

> On Tue, 2008-05-20 at 21:50 -0400, evands at pidgin.im wrote:
>> Skip the X-GOOGLE-TOKEN mech (given us by Google Talk when  
>> connecting with
>> SASL support), as we don't support it and its presence in the mechs  
>> list
>> makes us think we have another fallback left if we fail PLAIN,  
>> which can
>> distort the presented error message.
>
> I don't really know anything about this, but should we be checking  
> for a
> list of mechanisms we *do* support and ignoring everything else?

Possibly.  I'm not sure if it can be done before actually going  
through the SASL process, and at the point we're removing it we're  
building up things we're going to pass to cyrus-sasl.

Here's the problem... which in fixing other problems I'm responsible  
for generating:

We're given a list of mechanisms the server supports.  We're supposed  
to iterate through these, trying each one until they are exhausted.   
We do that; cryus-sasl basically skips over mechanisms in that list it  
doesn't know anything about.  The X-GOOGLE-TOKEN would therefore mean  
nothing to us if that were the end of the story.

After we exhaust all mechanisms, if the last mechanism ended in a real  
XMPP failure, such as "not authorized," we display that to the user.
However, if the last mechanism is effectively skipped by cyrus-sasl,  
we have two possibilities:
  1. *We never actually got to try a mechanism to completion.*
	  In that case, we should proceed to the legacy jabber:iq:auth  
authentication scheme - doing so is actually necessary to connect to  
certain jabberd-based servers, including Apple's iChat Server 10.5,  
which may provide a short list of SASL mechanisms (such as just GSSAPI  
and nothing else) and expect password-based authentication to always  
go through jabber:iq:auth.

  2. *We tried a mechanism to completion, it failed, and the last  
mechanism was skipped because it was invalid, as in the case of X- 
GOOGLE-TOKEN*
	In that case, we should not try jabber:iq:auth. Doing so, in fact,  
would violate XEP-0078... and also typically results in the server  
getting quite disgruntled. Instead of a nice "authentication failed"  
message we get a summary execution of the connection ('read error'  
typically).

Removing X-GOOGLE-TOKEN from the list prevents the only case of (2)  
that I've seen (GTalk provides "PLAIN X-GOOGLE-TOKEN" as its mech list).

Hopefully that clarifies the situation... maybe someone has a better  
solution than the existing one to suggest.

Cheers,
Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20080521/5778bc10/attachment.html>