Mercurial > pidgin.yaz
changeset 30290:757a608d6b71
jabber: Pluck evands's 2fcd83432 (the part that applies) to i.p.p
author | Paul Aurich <paul@darkrain42.org> |
---|---|
date | Tue, 04 May 2010 01:57:14 +0000 |
parents | ce52e101844a |
children | 5c639069557d |
files | libpurple/protocols/jabber/auth_cyrus.c |
diffstat | 1 files changed, 2 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:57:14 2010 +0000 @@ -252,24 +252,9 @@ 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 */ + + /* We found no mechs which could work */ break; /* Fatal errors. Give up and go home */