Mercurial > pidgin
annotate libpurple/protocols/jabber/adhoccommands.c @ 20671:4dd60add6a7c
Further cleanup of the msn prpl including preventing the authorization request callback from crashing if triggered after the account is disconnected. Also removal of some extraneous debuggery, there is more that needs to be removed.
author | Daniel Atallah <daniel.atallah@gmail.com> |
---|---|
date | Fri, 28 Sep 2007 01:57:55 +0000 |
parents | 5103485b4b26 |
children | bde477ec6a71 d1da36099088 |
rev | line source |
---|---|
17871
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 |
19698
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 |
17871
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 |
17882
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
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:
17872
diff
changeset
|
96 } |
17871
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 |
17904
49fe31a64716
Fixed a bug that prevented multi-stage ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents:
17884
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:
17884
diff
changeset
|
99 |
17871
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); |
17904
49fe31a64716
Fixed a bug that prevented multi-stage ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents:
17884
diff
changeset
|
105 jabber_iq_set_callback(iq, jabber_adhoc_parse, NULL); |
17871
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); |
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
|
112 if(actionhandle) |
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
|
113 xmlnode_set_attrib(command,"action",actionhandle); |
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
|
114 xmlnode_insert_child(command,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
|
115 |
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
|
116 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
|
117 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
|
118 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
|
119 } |
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
|
120 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
|
121 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
|
122 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
|
123 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
|
124 |
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 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
|
126 } |
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 |
17884
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:
17883
diff
changeset
|
128 static void jabber_adhoc_parse(JabberStream *js, xmlnode *packet, gpointer data) { |
17871
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 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
|
130 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
|
131 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
|
132 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
|
133 |
27fcb91ae08a
Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents:
18694
diff
changeset
|
134 if(type && !strcmp(type,"error")) { |
27fcb91ae08a
Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents:
18694
diff
changeset
|
135 char *msg = jabber_parse_error(js, packet); |
27fcb91ae08a
Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents:
18694
diff
changeset
|
136 if(!msg) |
27fcb91ae08a
Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents:
18694
diff
changeset
|
137 msg = g_strdup(_("Unknown Error")); |
27fcb91ae08a
Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents:
18694
diff
changeset
|
138 |
27fcb91ae08a
Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents:
18694
diff
changeset
|
139 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
|
140 _("Ad-Hoc Command Failed"), msg); |
27fcb91ae08a
Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents:
18694
diff
changeset
|
141 g_free(msg); |
27fcb91ae08a
Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents:
18694
diff
changeset
|
142 return; |
27fcb91ae08a
Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents:
18694
diff
changeset
|
143 } |
27fcb91ae08a
Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents:
18694
diff
changeset
|
144 if(!type || strcmp(type,"result")) |
27fcb91ae08a
Implemented error handling for ad-hoc commands.
Andreas Monitzer <pidgin@monitzer.com>
parents:
18694
diff
changeset
|
145 return; |
17871
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
|
146 |
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
|
147 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
|
148 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
|
149 |
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
|
150 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
|
151 /* 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
|
152 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
|
153 |
20058
5103485b4b26
Plug some memory leaks.
Sadrul Habib Chowdhury <imadil@gmail.com>
parents:
20000
diff
changeset
|
154 if(note) { |
5103485b4b26
Plug some memory leaks.
Sadrul Habib Chowdhury <imadil@gmail.com>
parents:
20000
diff
changeset
|
155 char *data = xmlnode_get_data(note); |
5103485b4b26
Plug some memory leaks.
Sadrul Habib Chowdhury <imadil@gmail.com>
parents:
20000
diff
changeset
|
156 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
|
157 g_free(data); |
5103485b4b26
Plug some memory leaks.
Sadrul Habib Chowdhury <imadil@gmail.com>
parents:
20000
diff
changeset
|
158 } |
17871
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 |
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
|
160 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
|
161 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
|
162 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
|
163 } |
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
|
164 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
|
165 /* 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
|
166 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
|
167 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
|
168 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
|
169 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
|
170 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
|
171 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
|
172 |
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 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
|
174 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
|
175 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
|
176 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
|
177 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
|
178 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
|
179 } 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
|
180 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
|
181 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
|
182 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
|
183 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
|
184 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
|
185 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
|
186 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
|
187 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
|
188 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
|
189 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
|
190 } |
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 } |
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 } |
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 |
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 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
|
195 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
|
196 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
|
197 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
|
198 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
|
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 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
|
201 } |
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 } |
17882
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:
17872
diff
changeset
|
203 |
17884
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:
17883
diff
changeset
|
204 void jabber_adhoc_execute_action(PurpleBlistNode *node, gpointer data) { |
17882
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:
17872
diff
changeset
|
205 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:
17872
diff
changeset
|
206 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:
17872
diff
changeset
|
207 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:
17872
diff
changeset
|
208 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:
17872
diff
changeset
|
209 |
17884
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:
17883
diff
changeset
|
210 jabber_adhoc_execute(js, cmd); |
17882
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:
17872
diff
changeset
|
211 } |
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:
17872
diff
changeset
|
212 } |
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:
17872
diff
changeset
|
213 |
17883
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:
17882
diff
changeset
|
214 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:
17882
diff
changeset
|
215 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:
17882
diff
changeset
|
216 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:
17882
diff
changeset
|
217 |
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:
17882
diff
changeset
|
218 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:
17882
diff
changeset
|
219 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:
17882
diff
changeset
|
220 |
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:
17882
diff
changeset
|
221 /* 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:
17882
diff
changeset
|
222 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:
17882
diff
changeset
|
223 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:
17882
diff
changeset
|
224 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:
17882
diff
changeset
|
225 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:
17882
diff
changeset
|
226 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:
17882
diff
changeset
|
227 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:
17882
diff
changeset
|
228 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:
17882
diff
changeset
|
229 } |
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:
17882
diff
changeset
|
230 |
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:
17882
diff
changeset
|
231 /* 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:
17882
diff
changeset
|
232 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:
17882
diff
changeset
|
233 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:
17882
diff
changeset
|
234 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:
17882
diff
changeset
|
235 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:
17882
diff
changeset
|
236 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:
17882
diff
changeset
|
237 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:
17882
diff
changeset
|
238 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:
17882
diff
changeset
|
239 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:
17882
diff
changeset
|
240 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:
17882
diff
changeset
|
241 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:
17882
diff
changeset
|
242 |
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:
17882
diff
changeset
|
243 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:
17882
diff
changeset
|
244 } |
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:
17882
diff
changeset
|
245 } |
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:
17882
diff
changeset
|
246 |
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:
17882
diff
changeset
|
247 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:
17882
diff
changeset
|
248 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:
17882
diff
changeset
|
249 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:
17882
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:
17882
diff
changeset
|
251 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:
17882
diff
changeset
|
252 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:
17882
diff
changeset
|
253 |
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:
17882
diff
changeset
|
254 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:
17882
diff
changeset
|
255 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:
17882
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:
17882
diff
changeset
|
257 |
17884
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:
17883
diff
changeset
|
258 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:
17883
diff
changeset
|
259 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:
17883
diff
changeset
|
260 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:
17883
diff
changeset
|
261 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:
17883
diff
changeset
|
262 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:
17883
diff
changeset
|
263 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:
17883
diff
changeset
|
264 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:
17883
diff
changeset
|
265 |
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:
17883
diff
changeset
|
266 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:
17883
diff
changeset
|
267 |
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:
17883
diff
changeset
|
268 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:
17883
diff
changeset
|
269 } |
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:
17883
diff
changeset
|
270 |
19699
680a3aea5eb6
Various warning fixes for the xmpp prpl.
Daniel Atallah <daniel.atallah@gmail.com>
parents:
19698
diff
changeset
|
271 static void jabber_adhoc_server_execute(PurplePluginAction *action) { |
17883
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:
17882
diff
changeset
|
272 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:
17882
diff
changeset
|
273 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:
17882
diff
changeset
|
274 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:
17882
diff
changeset
|
275 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:
17882
diff
changeset
|
276 |
17884
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:
17883
diff
changeset
|
277 jabber_adhoc_execute(js, cmd); |
17883
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:
17882
diff
changeset
|
278 } |
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:
17882
diff
changeset
|
279 } |
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:
17882
diff
changeset
|
280 |
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:
17882
diff
changeset
|
281 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:
17882
diff
changeset
|
282 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:
17904
diff
changeset
|
283 JabberBuddy *jb; |
17883
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:
17882
diff
changeset
|
284 |
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:
17904
diff
changeset
|
285 /* 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:
17904
diff
changeset
|
286 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:
17904
diff
changeset
|
287 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:
17904
diff
changeset
|
288 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:
17904
diff
changeset
|
289 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:
17904
diff
changeset
|
290 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:
17904
diff
changeset
|
291 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:
17904
diff
changeset
|
292 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:
17904
diff
changeset
|
293 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
|
294 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:
17904
diff
changeset
|
295 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:
17904
diff
changeset
|
296 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:
17904
diff
changeset
|
297 *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:
17904
diff
changeset
|
298 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:
17904
diff
changeset
|
299 } |
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:
17904
diff
changeset
|
300 } |
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:
17904
diff
changeset
|
301 } |
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:
17904
diff
changeset
|
302 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:
17904
diff
changeset
|
303 |
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:
17904
diff
changeset
|
304 /* now add server commands */ |
17883
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:
17882
diff
changeset
|
305 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:
17882
diff
changeset
|
306 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
|
307 PurplePluginAction *act = purple_plugin_action_new(cmd->name, jabber_adhoc_server_execute); |
17883
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:
17882
diff
changeset
|
308 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:
17882
diff
changeset
|
309 *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:
17882
diff
changeset
|
310 } |
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:
17882
diff
changeset
|
311 } |