# HG changeset patch # User Evan Schoenberg # Date 1197933514 0 # Node ID c95eaf2ae085f159294266269738bcd6d4c5b49c # Parent 944f7ada49e0cb3e4e0cc1740036bed9f36fea30 If no sasl mechs are appropriate, attempt a jabber:iq:auth connection. Note that this isn't the same as a failed authentication over sasl. Detailed comments in the code regarding my reasoning for this behavior. diff -r 944f7ada49e0 -r c95eaf2ae085 libpurple/protocols/jabber/auth.c --- a/libpurple/protocols/jabber/auth.c Mon Dec 17 20:37:30 2007 +0000 +++ b/libpurple/protocols/jabber/auth.c Mon Dec 17 23:18:34 2007 +0000 @@ -330,14 +330,21 @@ disallow_plaintext_auth); g_free(msg); return; - /* Everything else has failed, so fail the - * connection. Should probably have a better - * error here. - */ + } else { - purple_connection_error_reason (js->gc, - PURPLE_CONNECTION_ERROR_AUTHENTICATION_IMPOSSIBLE, - _("Server does not use any supported authentication method")); + /* 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 + */ + jabber_auth_start_old(js); return; } /* not reached */