changeset 30287:a044ddee7878

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.
author Evan Schoenberg <evan.s@dreskin.net>
date Tue, 04 May 2010 01:41:28 +0000
parents ce52e101844a
children a81d44a11d99
files libpurple/protocols/jabber/auth_cyrus.c
diffstat 1 files changed, 20 insertions(+), 17 deletions(-) [+]
line wrap: on
line diff
--- a/libpurple/protocols/jabber/auth_cyrus.c	Mon May 03 20:23:17 2010 +0000
+++ b/libpurple/protocols/jabber/auth_cyrus.c	Tue May 04 01:41:28 2010 +0000
@@ -252,24 +252,8 @@
 					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 @@
 			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;
 		}
 	}