Hi, I’m developing a XMPP client on an Openfire server. I have worked on Publish-Subscribe(XEP-0060) for several days. I found I can’t subscribe to the node which I had just created with another account. That means my account only be able to subscribe to the node which is created by itself. Does it works correctly in pep way(Because I found the Openfire seems to only support pep)? How to make the node visible to other accounts?
What response are you getting to the subscribe request? Which version of Openfire are you using? How is your client logging in? Try enabling debug logging and checking all.log for any problems.
FWIW, out applications rely on Openfire components being able to subscribe to pubsub nodes being created by anyone, so I know it can work.
Greg
Thanks for your response. Let me show your more details.
The Openfire version is 4.3.0 and I’m developing a XMPP client in iOS with XMPPFramework(But I think it doesn’t matter).
Firstly, I create a node named “abc” by send an IQ with an account which jid is "test7@joke.xfplay.com":
<iq type="set" id="002E8712-E7D0-4AFB-B612-6B9A1C4FD6B0"><pubsub xmlns="http://jabber.org/protocol/pubsub"><create node="abc"/><configure><x xmlns="jabber:x:data" type="submit"><field var="FORM_TYPE" type="hidden"><value>http://jabber.org/protocol/pubsub#node_config</value></field><field var="pubsub#notification_type"><value>headline</value></field><field var="pubsub#publish_model"><value>publishers</value></field><field var="pubsub#presence_based_delivery"><value>false</value></field><field var="pubsub#send_last_published_item"><value>never</value></field><field var="pubsub#max_items"><value>100000</value></field><field var="pubsub#access_model"><value>open</value></field><field var="pubsub#purge_offline"><value>0</value></field><field var="pubsub#deliver_notifications"><value>1</value></field><field var="pubsub#persist_items"><value>1</value></field><field var="pubsub#deliver_payloads"><value>1</value></field><field var="pubsub#title"><value>abc</value></field><field var="pubsub#item_expire"><value>604800</value></field></x></configure></pubsub></iq>
And The server returns an IQ:
<iq xmlns="jabber:client" type="result" id="002E8712-E7D0-4AFB-B612-6B9A1C4FD6B0" from="test7@joke.xfplay.com" to="test7@joke.xfplay.com/phone"></iq>
It creates successfully.
Next, I use another account which jid is ‘test4@joke.xfplay.com’ send an IQ to Openfire server to subscribe to the former node:
<iq type="set" id="A91C1B2E-5B1B-4EFF-8377-64B5BB7FF7B1"><pubsub xmlns="http://jabber.org/protocol/pubsub"><subscribe node="abc" jid="test4@joke.xfplay.com/phone"/></pubsub></iq>
The server returns an IQ to tell me it’s failed:
<iq xmlns="jabber:client" type="error" id="A91C1B2E-5B1B-4EFF-8377-64B5BB7FF7B1" from="test4@joke.xfplay.com" to="test4@joke.xfplay.com/phone"><pubsub xmlns="http://jabber.org/protocol/pubsub"><subscribe node="abc" jid="test4@joke.xfplay.com/phone"></subscribe></pubsub><error code="404" type="cancel"><item-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"></item-not-found></error></iq>
Well the 404 not found error tells me that it’s not finding the pubsub node. Which probably means you’re not creating it, despite the result IQ you’re getting.
I notice you’re setting the “to” field when creating the node; try sending the IQ creating the node to="pubsub.joke.xfplay.com" (I’m assuming your XMPP domain is joke.xfplay.com) - that should route the packet to the right location.
If that is the cause of the problem, I can’t help but think that Openfire should return a better response than “OK”!
Greg
PS. You can confirm if the node has been creating via the admin console; Server -> PubSub -> Node Summary.
Greg
I can confirm that the node had been created. I had retrieve all affiliations from server and check the database. It’s already there. I make a breakpoint in Openfire ‘PubSubEngine.java’. I found it always failed in line 645:
node = service.getNode(nodeID);
if (node == null) {
// Node does not exist. Return item-not-found error
sendErrorPacket(iq, PacketError.Condition.item_not_found, null);
return new ImmediateFuture<>();
}
It means the node can’t be found.
The ‘PEPService’ check the node is existing in the nodes. And the nodes is instantiated form database in ‘PubSubPersistenceManager.java’ in line 89:
private static final String LOAD_NODES =
"SELECT nodeID, leaf, creationDate, modificationDate, parent, deliverPayloads, " +
"maxPayloadSize, persistItems, maxItems, notifyConfigChanges, notifyDelete, " +
"notifyRetract, presenceBased, sendItemSubscribe, publisherModel, " +
"subscriptionEnabled, configSubscription, accessModel, payloadType, " +
"bodyXSLT, dataformXSLT, creator, description, language, name, " +
"replyPolicy, associationPolicy, maxLeafNodes FROM ofPubsubNode " +
"WHERE serviceID=?";
The serviceID is the bareID of account who crate the node. The code is in ‘PEPService.java’ in line 132:
public PEPService(XMPPServer server, String bareJID) {
this.serviceOwnerJID = bareJID;
I think this should be the reason why only the creator can subscribe his own node.
You’ve highlighted code in PEPService - this is for use with XEP-0163, Personal Eventing via Pubsub.
If you mean to use PEP, then I’ll have to defer to someone else (@guus?) as I’m not sure how that is supposed to work.
If you mean to use regular pubsub (XEP-60) then something is clearly going wrong; that’s implemented by PubSubModule, which doesn’t have these checks and should return a node. Is the node being created a PEP or regular node?
Greg
Do you mean that my Openfire sever is configured in wrong way? I really want to use regular pubsub but I can’t find where to configure this.
I think one or more of the following is true;
a) Openfire is configured wrongly (I’m not sure how, pubsub works immediately “out of the box” normally),
b) your belief that the code is going via PEPService.java is wrong (service.getNode(NodeID) can call either PEPService or PubSubModule) or
c) The requests you are sending are somehow not working. On inspection, the thing that strikes me is the missing to="pubsub.joke.xfplay.com" (both both creation and subscription) as already highlighted.
Greg