disapproval of revision 'cbff10cc0c168a9dbe05a1ae970d98806285f846'

In favor of Evan's changes

1 files changed, 17 insertions, 2 deletions

diff --git a/libpurple/protocols/jabber/auth_cyrus.c b/libpurple/protocols/jabber/auth_cyrus.c
index 3f9e388831..ba8fb68940 100644
--- a/libpurple/protocols/jabber/auth_cyrus.c
+++ b/libpurple/protocols/jabber/auth_cyrus.c
@@ -252,9 +252,24 @@ jabber_auth_start_cyrus(JabberStream *js, xmlnode **reply, char **error)
 					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;
 				}
-
-				/* We found no mechs which could work */
+				/* not reached */
 				break;
 
 				/* Fatal errors. Give up and go home */