Is there *ANY* chance that ejabberd 2.0.0 rc1 would block iq's that have a "query xmlns='jabber:iq:rpc'" in them? (there is also all the appropriate xmlrpc call stuff in there too..)
I keep getting a 503 (service-unavailable) from a rpc message send from one bot to another, and the bot code the message is addressed to doesn't throw a 503 anywhere.... I'm stumped.
-thx, hope it's not snowing where you are.
-kristofer
If you are getting harassing
If you are getting harassing stanzas from some jabber user, you can setup a privacy list to block that user.
No, I am trying to move RPC
No, I am trying to move RPC messages thru ejabberd 2.0 (rc1), using the jabber:iq:rpc namespace. I want to create a bot that can talk to a user and then commnicate with other bots of its kind by using the jabber RPC (jep-0009) ideas. The problem is, in both ruby and python, ejabberd 2.0 server doesn't seem to pass RPC messages, I get a 503 from the Server, not form the bot the RPC is addressed to.
thx,
Specify the full JID, including the resource
ejabberd 2.0 server doesn't seem to pass RPC messages, I get a 503 from the Server, not form the bot the RPC is addressed to.
I have ejabberd 2.0.0-rc1, with vhost 'localhost'. I create two accounts: 'user1' and 'user2'. I start Tkabber two times, and in each client I login to a different account. The resources are 'Tka' for both users.
First, user1 sends this packet:
<iq to='user2@localhost/Tka' type='get'>
<query xmlns='jabber:iq:version'/>
</iq>
user2 receives the query and answers correctly. The result is that user1 receives a nice answer:
<iq from='user2@localhost/Tka'
type='result'
to='user1@localhost/Tka'>
<query xmlns='jabber:iq:version'>
<name>Tkabber</name>
<version>0.10.0-svn-20080115 (Tcl/Tk 8.4.18)</version>
<os>Debian GNU/Linux lenny/sid 2.6.24-1-686</os>
</query>
</iq>
Now I'll send the IQ query to the bare JID, without specifying the resource of the destination:
<iq to='user2@localhost' type='get'>
<query xmlns='jabber:iq:version'/>
</iq>
In this case, user2 doesn't receive the query because ejabberd doesn't deliver it. Instead, ejabberd immediately complains, and user1 receives this answer:
<iq from='user2@localhost'
type='error'
to='user1@localhost/Tka'>
<query xmlns='jabber:iq:version'/>
<error type='cancel' code='503'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
If you look closely the examples in XEP-0009, all of them specify full JIDs in the 'to' stanza attribute: all the JIDs include the resource.
I don't know if the server should block or not iq queries when the destination JID is just a bare JID.
It looks like the correct
It looks like the correct behaviour to me from the XMPP specifications itself. I think IQ only make sense when targetting an actual resource: Otherwise, you can end up sending packets to a client that do not support your RPC.
--
Process-one
Mickaël Rémond
Yes. the Resource is required
Yes, adding the resource (one of the few combinatorial choices I did not test before posting) makes my test apps work just fine. Thanks to mremond & badlop!