comparison libpurple/protocols/jabber/auth.c @ 27039:9a79f8a99259

Set charset=utf-8 when cyrus sasl doesn't include it. Both deryni and my reading of the digest md5 cyrus plugin is that the response will never actually include the charset (digestmd5.c:make_client_response, look for IsUTF8). I future-proofed this code by checking for it anyway. To be polite for older servers, we might want to only send this if the server sent charset=utf-8 in the challenge (and encode everything to ISO-8859-1). However, the RFC doesn't say always sending it is wrong (and that's what the in-tree implementation does).

27037:f3b0232ef1ea

			return;
		} else {
			response = xmlnode_new("response");
			xmlnode_set_namespace(response, "urn:ietf:params:xml:ns:xmpp-sasl");
			if (clen > 0) {
				enc_out = purple_base64_encode((unsigned char*)c_out, clen);
				xmlnode_insert_data(response, enc_out, -1);
				g_free(enc_out);
			}
			jabber_send(js, response);
			xmlnode_free(response);

27039:9a79f8a99259

			return;
		} else {
			response = xmlnode_new("response");
			xmlnode_set_namespace(response, "urn:ietf:params:xml:ns:xmpp-sasl");
			if (clen > 0) {
				/* Cyrus SASL 2.1.22 appears to contain code to add the charset
				 * to the response but there is no possibility it will be executed.
				 * My reading of the digestmd5 plugin indicates the username and
				 * realm are always encoded in UTF-8 (they seem to be the values
				 * we pass in), so we need to ensure charset=utf-8 is set.
				 */
				if (strstr(c_out, ",charset="))
					enc_out = purple_base64_encode((unsigned char*)c_out, clen);
				else {
					char *tmp = g_strdup_printf("%s,charset=utf-8", c_out);
					enc_out = purple_base64_encode((unsigned char*)c_out, clen + 14);
					g_free(tmp);
				}

				xmlnode_insert_data(response, enc_out, -1);
				g_free(enc_out);
			}
			jabber_send(js, response);
			xmlnode_free(response);