view libpurple/dbus-purple.h @ 25452:6a0304f317cf

I was hoping this wouldn't be necessary, but it seems that the possibility has increased now that we update the display name in the AB. If two SOAP requests fail because of outdated tokens for the same server, it's possible that the second one could fail miserably. That's because both times, the update request would be made with the original cipher secret. However, the response for the first request would overwrite this secret, and the second response would attempt decryption with this new secret instead of the original. Now, we queue up the callbacks if a token-update is already in progress. This results in a single update if there happens to be multiple failures at a time, and it stops this incorrect decryption problem. Fixes #8415.

/*
 * purple
 *
 * Purple is the legal property of its developers, whose names are too numerous
 * to list here.  Please refer to the COPYRIGHT file distributed with this
 * source distribution.
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02111-1301  USA
 *
 */

#ifndef _DBUS_PURPLE_H_
#define _DBUS_PURPLE_H_

#define DBUS_SERVICE_PURPLE      "im.pidgin.purple.PurpleService"
#define DBUS_PATH_PURPLE         "/im/pidgin/purple/PurpleObject"
#define DBUS_INTERFACE_PURPLE    "im.pidgin.purple.PurpleInterface"

#endif /* _DBUS_PURPLE_H_ */