Mercurial > pidgin.yaz
view libpurple/purple-send-async @ 30288:a81d44a11d99
If SASL authentication fails, we generally shouldn't be setting an error
message, as the actual error was communicated via the
"urn:ietf:params:xml:ns:xmpp-sasl" failure stanza. Setting an error means that
jabber_auth_handle_failure() won't ever call jabber_parse_error() to extract
the actual error message and interpretation.
For example, if authentication fails, previously we would show "SASL
authentication failed" and think it was a PURPLE_CONNECTION_ERROR_NETWORK_ERROR
which is incorrect. Now, jabber_parse_error() gets a chance to return
"Not Authorized", clear the saved password, and return
PURPLE_CONNECTION_ERROR_AUTHENTICATION_FAILED.
We should still set this error message if there is an internal SASL failure
leading to SASL_BADPARAM or SASL_NOMEM.
author | Evan Schoenberg <evan.s@dreskin.net> |
---|---|
date | Tue, 04 May 2010 01:46:40 +0000 |
parents | cea56d000b16 |
children |
line wrap: on
line source
#!/bin/sh METHOD_NAME=$1 if test -z "$METHOD_NAME" then cat <<EOF This program calls purple API functions using DBus. As opposed to purple-send, it does not print the return value. Usage: $0 method-name type1:parameter1 type2:parameter2 ... This shell script just invokes dbus-send, see man dbus-send for how to specify the parameters. Examples: $0 PurpleCoreQuit Use dbus-viewer to get the list of supported functions and their parameters. EOF exit 1 fi shift dbus-send --dest=im.pidgin.purple.PurpleService --type=method_call /im/pidgin/purple/PurpleObject im.pidgin.purple.PurpleInterface.$METHOD_NAME "$@"