pidgin: ce00ec5b: Improve on a hack I commited in 12/2007 ..

[evands at pidgin.im]

-----------------------------------------------------------------
Revision: ce00ec5bb0ec76da8360bd2098fb23cf7ba3e0ad
Ancestor: 82175cfc320b7c831512ecc2a00beec2a86b7a2a
Author: evands at pidgin.im
Date: 2010-05-04T01:41:28
Branch: im.pidgin.pidgin
URL: http://d.pidgin.im/viewmtn/revision/info/ce00ec5bb0ec76da8360bd2098fb23cf7ba3e0ad

Modified files:
        libpurple/protocols/jabber/auth_cyrus.c

ChangeLog: 

Improve on a hack I commited in 12/2007 which allows connection via XMPP to iChat Server 10.5 when CYRUS-SASL is compiled with GSSAPI support but no GSSAPI credentials are valid to connect to the server. Instead of always trying jabber:iq:auth if all SASL mechs fail, we now only do so in the specific case of a single mech having been attempted and that mech being GSSAPI. In general, this means that we now gracefully fail authentication with SASL rather than getting ourselves booted from servers not expecting a jabber:iq:auth stanza.

-------------- next part --------------
============================================================
--- libpurple/protocols/jabber/auth_cyrus.c	ea44881795aca9d4a6d2926935a069f284278479
+++ libpurple/protocols/jabber/auth_cyrus.c	3936dda160a35b577d641d0cfaba9aeee31d4db0
@@ -252,24 +252,8 @@ jabber_auth_start_cyrus(JabberStream *js
 					g_free(msg);
 					return JABBER_SASL_STATE_CONTINUE;
 
-				} else {
-					/* We have no mechs which can work.
-					 * Try falling back on the old jabber:iq:auth method. We get here if the server supports
-					 * one or more sasl mechs, we are compiled with cyrus-sasl support, but we support or can connect with none of
-					 * the offerred mechs. jabberd 2.0 w/ SASL and Apple's iChat Server 10.5 both handle and expect
-					 * jabber:iq:auth in this situation.  iChat Server in particular offers SASL GSSAPI by default, which is often
-					 * not configured on the client side, and expects a fallback to jabber:iq:auth when it (predictably) fails.
-					 *
-					 * Note: xep-0078 points out that using jabber:iq:auth after a sasl failure is wrong. However,
-					 * I believe this refers to actual authentication failure, not a simple lack of concordant mechanisms.
-					 * Doing otherwise means that simply compiling with SASL support renders the client unable to connect to servers
-					 * which would connect without issue otherwise. -evands
-					 */
-					js->auth_mech = NULL;
-					jabber_auth_start_old(js);
-					return JABBER_SASL_STATE_CONTINUE;
 				}
-				/* not reached */
+
 				break;
 
 				/* Fatal errors. Give up and go home */
@@ -545,6 +529,25 @@ jabber_cyrus_handle_failure(JabberStream
 			sasl_dispose(&js->sasl);
 
 			return jabber_auth_start_cyrus(js, reply, error);
+
+		} else if ((js->auth_fail_count == 1) && 
+				   (js->current_mech && g_str_equal(js->current_mech, "GSSAPI"))) {
+			/* If we tried GSSAPI first, it failed, and it was the only method we had to try, try jabber:iq:auth
+			 * for compatibility with iChat 10.5 Server.
+			 *
+			 * iChat Server 10.5  offers SASL GSSAPI by default, which is often
+			 * not configured on the client side, and expects a fallback to jabber:iq:auth when it (predictably) fails.
+			 *
+			 * Note: xep-0078 points out that using jabber:iq:auth after a sasl failure is wrong. However,
+			 * I believe this refers to actual authentication failure, not a simple lack of concordant mechanisms.
+			 * Doing otherwise means that simply compiling with SASL support renders the client unable to connect to servers
+			 * which would connect without issue otherwise. -evands
+			 */
+			sasl_dispose(&js->sasl);
+			js->sasl = NULL;
+			js->auth_mech = NULL;
+			jabber_auth_start_old(js);
+			return JABBER_SASL_STATE_CONTINUE;
 		}
 	}