adium.1-4: 2fcd8343: If we connect, are offerred GSSAPI *only...

evands at pidgin.im evands at pidgin.im
Mon May 3 14:35:37 EDT 2010


-----------------------------------------------------------------
Revision: 2fcd834324b05d3becf6878db8ce1c474578e720
Ancestor: 47085b9fe64551b697ca9ba601b8c0323e47c449
Author: evands at pidgin.im
Date: 2010-05-03T18:29:28
Branch: im.pidgin.adium.1-4
URL: http://d.pidgin.im/viewmtn/revision/info/2fcd834324b05d3becf6878db8ce1c474578e720

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

ChangeLog: 

If we connect, are offerred GSSAPI *only*, and fail it, then try jabber:iq:auth for iChat Server 10.5
compatibility. However, remove attempts to fall back on jabber:iq:auth if any other sequence occurs
and we run out of SASL mechanisms, as in no other situation is it appropriate.

I believe this is a more proper fix (by being less aggressive with the fallback) for Adium's #8108.

-------------- next part --------------
============================================================
--- libpurple/protocols/jabber/auth_cyrus.c	a3e535e42d78f3cf833aa5fea326edc74a8c5531
+++ libpurple/protocols/jabber/auth_cyrus.c	aafb75c25acb032db5f51eff65172776e5b3ed17
@@ -252,23 +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;
 
@@ -564,6 +549,14 @@ jabber_cyrus_handle_failure(JabberStream
 		} else if (tried_gssapi_first) {
 			/* If we tried GSSAPI first, it failed, and it was our only shot, 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;


More information about the Commits mailing list