annotate libpurple/protocols/jabber/adhoccommands.c @ 23713:907f5f41e32a

Remove a bunch of *_init() and *_uninit() functions that don't make sense for Perl plugins to call. Plug a couple leaks. Mark a couple functions that need to be fixed.
author Daniel Atallah <daniel.atallah@gmail.com>
date Thu, 07 Aug 2008 03:10:44 +0000
parents 38cc722159ff
children 16734635febf a1b2f2dd4849
Ignore whitespace changes - Everywhere: Within whitespace: At end of lines:
rev   line source
17598
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
1 /*
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
2 * purple - Jabber Protocol Plugin
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
3 *
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
4 * Copyright (C) 2007, Andreas Monitzer <andy@monitzer.com>
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
5 *
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
6 * This program is free software; you can redistribute it and/or modify
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
7 * it under the terms of the GNU General Public License as published by
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
8 * the Free Software Foundation; either version 2 of the License, or
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
9 * (at your option) any later version.
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
10 *
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
11 * This program is distributed in the hope that it will be useful,
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
12 * but WITHOUT ANY WARRANTY; without even the implied warranty of
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
13 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
14 * GNU General Public License for more details.
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
15 *
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
16 * You should have received a copy of the GNU General Public License
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
17 * along with this program; if not, write to the Free Software
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
18 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
19 *
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
20 */
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
21
19697
d32ed28cf645 Fix mingw build of xmpp prpl
Daniel Atallah <daniel.atallah@gmail.com>
parents: 18697
diff changeset
22 #include "internal.h"
d32ed28cf645 Fix mingw build of xmpp prpl
Daniel Atallah <daniel.atallah@gmail.com>
parents: 18697
diff changeset
23
17598
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
24 #include "adhoccommands.h"
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
25 #include <string.h>
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
26 #include "internal.h"
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
27 #include "xdata.h"
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
28 #include "iq.h"
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
29 #include "request.h"
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
30
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
31 static void do_adhoc_ignoreme(JabberStream *js, ...) {
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
32 /* we don't have to do anything */
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
33 }
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
34
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
35 typedef struct _JabberAdHocActionInfo {
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
36 char *sessionid;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
37 char *who;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
38 char *node;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
39 GList *actionslist;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
40 } JabberAdHocActionInfo;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
41
17609
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
42 void jabber_adhoc_disco_result_cb(JabberStream *js, xmlnode *packet, gpointer data) {
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
43 const char *from = xmlnode_get_attrib(packet, "from");
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
44 const char *type = xmlnode_get_attrib(packet, "type");
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
45 const char *node;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
46 xmlnode *query, *item;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
47 JabberID *jabberid;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
48 JabberBuddy *jb;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
49 JabberBuddyResource *jbr = NULL;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
50
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
51 if(strcmp(type, "result"))
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
52 return;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
53
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
54 query = xmlnode_get_child_with_namespace(packet,"query","http://jabber.org/protocol/disco#items");
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
55 if(!query)
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
56 return;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
57 node = xmlnode_get_attrib(query,"node");
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
58 if(!node || strcmp(node, "http://jabber.org/protocol/commands"))
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
59 return;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
60
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
61 if((jabberid = jabber_id_new(from))) {
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
62 if(jabberid->resource && (jb = jabber_buddy_find(js, from, TRUE)))
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
63 jbr = jabber_buddy_find_resource(jb, jabberid->resource);
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
64 jabber_id_free(jabberid);
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
65 }
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
66
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
67 if(!jbr)
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
68 return;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
69
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
70 if(jbr->commands) {
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
71 /* since the list we just received is complete, wipe the old one */
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
72 while(jbr->commands) {
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
73 JabberAdHocCommands *cmd = jbr->commands->data;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
74 g_free(cmd->jid);
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
75 g_free(cmd->node);
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
76 g_free(cmd->name);
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
77 g_free(cmd);
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
78 jbr->commands = g_list_delete_link(jbr->commands, jbr->commands);
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
79 }
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
80 }
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
81
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
82 for(item = query->child; item; item = item->next) {
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
83 JabberAdHocCommands *cmd;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
84 if(item->type != XMLNODE_TYPE_TAG)
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
85 continue;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
86 if(strcmp(item->name, "item"))
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
87 continue;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
88 cmd = g_new0(JabberAdHocCommands, 1);
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
89
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
90 cmd->jid = g_strdup(xmlnode_get_attrib(item,"jid"));
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
91 cmd->node = g_strdup(xmlnode_get_attrib(item,"node"));
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
92 cmd->name = g_strdup(xmlnode_get_attrib(item,"name"));
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
93
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
94 jbr->commands = g_list_append(jbr->commands,cmd);
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
95 }
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
96 }
17598
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
97
17631
49fe31a64716 Fixed a bug that prevented multi-stage ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17611
diff changeset
98 static void jabber_adhoc_parse(JabberStream *js, xmlnode *packet, gpointer data);
49fe31a64716 Fixed a bug that prevented multi-stage ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17611
diff changeset
99
17598
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
100 static void do_adhoc_action_cb(JabberStream *js, xmlnode *result, const char *actionhandle, gpointer user_data) {
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
101 xmlnode *command;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
102 GList *action;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
103 JabberAdHocActionInfo *actionInfo = user_data;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
104 JabberIq *iq = jabber_iq_new(js, JABBER_IQ_SET);
17631
49fe31a64716 Fixed a bug that prevented multi-stage ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17611
diff changeset
105 jabber_iq_set_callback(iq, jabber_adhoc_parse, NULL);
17598
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
106
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
107 xmlnode_set_attrib(iq->node, "to", actionInfo->who);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
108 command = xmlnode_new_child(iq->node,"command");
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
109 xmlnode_set_namespace(command,"http://jabber.org/protocol/commands");
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
110 xmlnode_set_attrib(command,"sessionid",actionInfo->sessionid);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
111 xmlnode_set_attrib(command,"node",actionInfo->node);
21176
d1da36099088 Fixed cancelling ad-hoc commands
Andreas Monitzer <pidgin@monitzer.com>
parents: 20058
diff changeset
112
d1da36099088 Fixed cancelling ad-hoc commands
Andreas Monitzer <pidgin@monitzer.com>
parents: 20058
diff changeset
113 /* cancel is handled differently on ad-hoc commands than regular forms */
d1da36099088 Fixed cancelling ad-hoc commands
Andreas Monitzer <pidgin@monitzer.com>
parents: 20058
diff changeset
114 if(!strcmp(xmlnode_get_namespace(result),"jabber:x:data") && !strcmp(xmlnode_get_attrib(result, "type"),"cancel")) {
d1da36099088 Fixed cancelling ad-hoc commands
Andreas Monitzer <pidgin@monitzer.com>
parents: 20058
diff changeset
115 xmlnode_set_attrib(command,"action","cancel");
d1da36099088 Fixed cancelling ad-hoc commands
Andreas Monitzer <pidgin@monitzer.com>
parents: 20058
diff changeset
116 } else {
d1da36099088 Fixed cancelling ad-hoc commands
Andreas Monitzer <pidgin@monitzer.com>
parents: 20058
diff changeset
117 if(actionhandle)
d1da36099088 Fixed cancelling ad-hoc commands
Andreas Monitzer <pidgin@monitzer.com>
parents: 20058
diff changeset
118 xmlnode_set_attrib(command,"action",actionhandle);
d1da36099088 Fixed cancelling ad-hoc commands
Andreas Monitzer <pidgin@monitzer.com>
parents: 20058
diff changeset
119 xmlnode_insert_child(command,result);
d1da36099088 Fixed cancelling ad-hoc commands
Andreas Monitzer <pidgin@monitzer.com>
parents: 20058
diff changeset
120 }
17598
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
121
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
122 for(action = actionInfo->actionslist; action; action = g_list_next(action)) {
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
123 char *handle = action->data;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
124 g_free(handle);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
125 }
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
126 g_list_free(actionInfo->actionslist);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
127 g_free(actionInfo->sessionid);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
128 g_free(actionInfo->who);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
129 g_free(actionInfo->node);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
130
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
131 jabber_iq_send(iq);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
132 }
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
133
17611
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
134 static void jabber_adhoc_parse(JabberStream *js, xmlnode *packet, gpointer data) {
17598
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
135 xmlnode *command = xmlnode_get_child_with_namespace(packet, "command", "http://jabber.org/protocol/commands");
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
136 const char *status = xmlnode_get_attrib(command,"status");
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
137 xmlnode *xdata = xmlnode_get_child_with_namespace(command,"x","jabber:x:data");
18697
27fcb91ae08a Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 18694
diff changeset
138 const char *type = xmlnode_get_attrib(packet,"type");
27fcb91ae08a Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 18694
diff changeset
139
27fcb91ae08a Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 18694
diff changeset
140 if(type && !strcmp(type,"error")) {
20814
bde477ec6a71 Stop jabber setting wants_to_die itself. This involved plumbing disconnection
Will Thompson <will.thompson@collabora.co.uk>
parents: 20058
diff changeset
141 char *msg = jabber_parse_error(js, packet, NULL);
18697
27fcb91ae08a Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 18694
diff changeset
142 if(!msg)
27fcb91ae08a Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 18694
diff changeset
143 msg = g_strdup(_("Unknown Error"));
27fcb91ae08a Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 18694
diff changeset
144
27fcb91ae08a Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 18694
diff changeset
145 purple_notify_error(NULL, _("Ad-Hoc Command Failed"),
27fcb91ae08a Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 18694
diff changeset
146 _("Ad-Hoc Command Failed"), msg);
27fcb91ae08a Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 18694
diff changeset
147 g_free(msg);
27fcb91ae08a Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 18694
diff changeset
148 return;
27fcb91ae08a Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 18694
diff changeset
149 }
27fcb91ae08a Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 18694
diff changeset
150 if(!type || strcmp(type,"result"))
27fcb91ae08a Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents: 18694
diff changeset
151 return;
17598
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
152
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
153 if(!status)
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
154 return;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
155
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
156 if(!strcmp(status,"completed")) {
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
157 /* display result */
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
158 xmlnode *note = xmlnode_get_child(command,"note");
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
159
20058
5103485b4b26 Plug some memory leaks.
Sadrul Habib Chowdhury <imadil@gmail.com>
parents: 20000
diff changeset
160 if(note) {
5103485b4b26 Plug some memory leaks.
Sadrul Habib Chowdhury <imadil@gmail.com>
parents: 20000
diff changeset
161 char *data = xmlnode_get_data(note);
5103485b4b26 Plug some memory leaks.
Sadrul Habib Chowdhury <imadil@gmail.com>
parents: 20000
diff changeset
162 purple_notify_info(NULL, xmlnode_get_attrib(packet, "from"), data, NULL);
5103485b4b26 Plug some memory leaks.
Sadrul Habib Chowdhury <imadil@gmail.com>
parents: 20000
diff changeset
163 g_free(data);
5103485b4b26 Plug some memory leaks.
Sadrul Habib Chowdhury <imadil@gmail.com>
parents: 20000
diff changeset
164 }
17598
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
165
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
166 if(xdata)
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
167 jabber_x_data_request(js, xdata, (jabber_x_data_cb)do_adhoc_ignoreme, NULL);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
168 return;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
169 }
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
170 if(!strcmp(status,"executing")) {
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
171 /* this command needs more steps */
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
172 xmlnode *actions, *action;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
173 int actionindex = 0;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
174 GList *actionslist = NULL;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
175 JabberAdHocActionInfo *actionInfo;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
176 if(!xdata)
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
177 return; /* shouldn't happen */
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
178
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
179 actions = xmlnode_get_child(command,"actions");
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
180 if(!actions) {
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
181 JabberXDataAction *defaultaction = g_new0(JabberXDataAction, 1);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
182 defaultaction->name = g_strdup(_("execute"));
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
183 defaultaction->handle = g_strdup("execute");
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
184 actionslist = g_list_append(actionslist, defaultaction);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
185 } else {
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
186 const char *defaultactionhandle = xmlnode_get_attrib(actions, "execute");
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
187 int index = 0;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
188 for(action = actions->child; action; action = action->next, ++index) {
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
189 if(action->type == XMLNODE_TYPE_TAG) {
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
190 JabberXDataAction *newaction = g_new0(JabberXDataAction, 1);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
191 newaction->name = g_strdup(_(action->name));
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
192 newaction->handle = g_strdup(action->name);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
193 actionslist = g_list_append(actionslist, newaction);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
194 if(defaultactionhandle && !strcmp(defaultactionhandle, action->name))
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
195 actionindex = index;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
196 }
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
197 }
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
198 }
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
199
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
200 actionInfo = g_new0(JabberAdHocActionInfo, 1);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
201 actionInfo->sessionid = g_strdup(xmlnode_get_attrib(command,"sessionid"));
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
202 actionInfo->who = g_strdup(xmlnode_get_attrib(packet,"from"));
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
203 actionInfo->node = g_strdup(xmlnode_get_attrib(command,"node"));
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
204 actionInfo->actionslist = actionslist;
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
205
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
206 jabber_x_data_request_with_actions(js,xdata,actionslist,actionindex,do_adhoc_action_cb,actionInfo);
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
207 }
43df07968000 Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <pidgin@monitzer.com>
parents:
diff changeset
208 }
17609
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
209
17611
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
210 void jabber_adhoc_execute_action(PurpleBlistNode *node, gpointer data) {
17609
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
211 if (PURPLE_BLIST_NODE_IS_BUDDY(node)) {
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
212 JabberAdHocCommands *cmd = data;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
213 PurpleBuddy *buddy = (PurpleBuddy *) node;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
214 JabberStream *js = purple_account_get_connection(buddy->account)->proto_data;
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
215
17611
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
216 jabber_adhoc_execute(js, cmd);
17609
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
217 }
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
218 }
f88b3a093cba Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17599
diff changeset
219
17610
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
220 static void jabber_adhoc_server_got_list_cb(JabberStream *js, xmlnode *packet, gpointer data) {
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
221 xmlnode *query = xmlnode_get_child_with_namespace(packet, "query", "http://jabber.org/protocol/disco#items");
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
222 xmlnode *item;
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
223
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
224 if(!query)
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
225 return;
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
226
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
227 /* clean current list (just in case there is one) */
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
228 while(js->commands) {
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
229 JabberAdHocCommands *cmd = js->commands->data;
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
230 g_free(cmd->jid);
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
231 g_free(cmd->node);
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
232 g_free(cmd->node);
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
233 g_free(cmd);
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
234 js->commands = g_list_delete_link(js->commands, js->commands);
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
235 }
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
236
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
237 /* re-fill list */
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
238 for(item = query->child; item; item = item->next) {
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
239 JabberAdHocCommands *cmd;
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
240 if(item->type != XMLNODE_TYPE_TAG)
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
241 continue;
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
242 if(strcmp(item->name, "item"))
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
243 continue;
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
244 cmd = g_new0(JabberAdHocCommands, 1);
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
245 cmd->jid = g_strdup(xmlnode_get_attrib(item,"jid"));
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
246 cmd->node = g_strdup(xmlnode_get_attrib(item,"node"));
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
247 cmd->name = g_strdup(xmlnode_get_attrib(item,"name"));
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
248
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
249 js->commands = g_list_append(js->commands,cmd);
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
250 }
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
251 }
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
252
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
253 void jabber_adhoc_server_get_list(JabberStream *js) {
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
254 JabberIq *iq = jabber_iq_new_query(js,JABBER_IQ_GET,"http://jabber.org/protocol/disco#items");
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
255 xmlnode *query = xmlnode_get_child_with_namespace(iq->node,"query","http://jabber.org/protocol/disco#items");
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
256
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
257 xmlnode_set_attrib(iq->node,"to",js->user->domain);
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
258 xmlnode_set_attrib(query,"node","http://jabber.org/protocol/commands");
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
259
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
260 jabber_iq_set_callback(iq,jabber_adhoc_server_got_list_cb,NULL);
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
261 jabber_iq_send(iq);
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
262 }
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
263
17611
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
264 void jabber_adhoc_execute(JabberStream *js, JabberAdHocCommands *cmd) {
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
265 JabberIq *iq = jabber_iq_new(js, JABBER_IQ_SET);
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
266 xmlnode *command = xmlnode_new_child(iq->node,"command");
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
267 xmlnode_set_attrib(iq->node,"to",cmd->jid);
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
268 xmlnode_set_namespace(command,"http://jabber.org/protocol/commands");
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
269 xmlnode_set_attrib(command,"node",cmd->node);
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
270 xmlnode_set_attrib(command,"action","execute");
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
271
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
272 jabber_iq_set_callback(iq,jabber_adhoc_parse,NULL);
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
273
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
274 jabber_iq_send(iq);
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
275 }
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
276
19698
680a3aea5eb6 Various warning fixes for the xmpp prpl.
Daniel Atallah <daniel.atallah@gmail.com>
parents: 19697
diff changeset
277 static void jabber_adhoc_server_execute(PurplePluginAction *action) {
17610
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
278 JabberAdHocCommands *cmd = action->user_data;
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
279 if(cmd) {
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
280 PurpleConnection *gc = (PurpleConnection *) action->context;
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
281 JabberStream *js = gc->proto_data;
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
282
17611
feac55968392 Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17610
diff changeset
283 jabber_adhoc_execute(js, cmd);
17610
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
284 }
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
285 }
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
286
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
287 void jabber_adhoc_init_server_commands(JabberStream *js, GList **m) {
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
288 GList *cmdlst;
18691
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
289 JabberBuddy *jb;
17610
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
290
18691
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
291 /* also add commands for other clients connected to the same account on another resource */
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
292 char *accountname = g_strdup_printf("%s@%s", js->user->node, js->user->domain);
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
293 if((jb = jabber_buddy_find(js, accountname, TRUE))) {
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
294 GList *iter;
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
295 for(iter = jb->resources; iter; iter = g_list_next(iter)) {
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
296 JabberBuddyResource *jbr = iter->data;
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
297 GList *riter;
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
298 for(riter = jbr->commands; riter; riter = g_list_next(riter)) {
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
299 JabberAdHocCommands *cmd = riter->data;
18694
c72d2458b22e Switched formatting of the ad-hoc commands to be less intimidating
Andreas Monitzer <pidgin@monitzer.com>
parents: 18691
diff changeset
300 char *cmdname = g_strdup_printf("%s (%s)",cmd->name,jbr->name);
18691
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
301 PurplePluginAction *act = purple_plugin_action_new(cmdname, jabber_adhoc_server_execute);
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
302 act->user_data = cmd;
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
303 *m = g_list_append(*m, act);
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
304 g_free(cmdname);
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
305 }
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
306 }
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
307 }
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
308 g_free(accountname);
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
309
54a5fbeadd7c Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <pidgin@monitzer.com>
parents: 17631
diff changeset
310 /* now add server commands */
17610
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
311 for(cmdlst = js->commands; cmdlst; cmdlst = g_list_next(cmdlst)) {
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
312 JabberAdHocCommands *cmd = cmdlst->data;
18694
c72d2458b22e Switched formatting of the ad-hoc commands to be less intimidating
Andreas Monitzer <pidgin@monitzer.com>
parents: 18691
diff changeset
313 PurplePluginAction *act = purple_plugin_action_new(cmd->name, jabber_adhoc_server_execute);
17610
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
314 act->user_data = cmd;
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
315 *m = g_list_append(*m, act);
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
316 }
9a19c46adf66 The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <pidgin@monitzer.com>
parents: 17609
diff changeset
317 }