Mercurial > pidgin.yaz
changeset 30291:5c639069557d
disapproval of revision '5f410e729e7a8a2e46752d46b37a7c11e17d5ed7'
In favor of Evan's changes
| author | Paul Aurich <paul@darkrain42.org> |
|---|---|
| date | Tue, 04 May 2010 02:22:26 +0000 |
| parents | 757a608d6b71 |
| children | 7b712cf17262 |
| files | libpurple/protocols/jabber/auth_cyrus.c |
| diffstat | 1 files changed, 17 insertions(+), 2 deletions(-) [+] |
line wrap: on
line diff
--- a/libpurple/protocols/jabber/auth_cyrus.c Tue May 04 01:57:14 2010 +0000 +++ b/libpurple/protocols/jabber/auth_cyrus.c Tue May 04 02:22:26 2010 +0000 @@ -252,9 +252,24 @@ 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 */