Project

General

Profile

disco#items and disco#info don't work without JID resource in 2.2.1

Igor Khomenko
Added almost 5 years ago

I have just upgraded Tigase 5.1beta to Tigase 5.2. And also updated muc component to 2.2.1 version.

What I noticed is that disco#items and disco#info don't work without JID resource in 2.2.1

For example, this is disco#items query:

@Override
public void process(Packet element) throws MUCException {
    log.log(Level.INFO, "MUC element: " + element);

...

2014-06-11 12:25:09.350 [in_0-muc]         DiscoItemsModule.process()         INFO:     MUC element: from=sess-man@ip-10-16-235-20.ec2.internal, to=null, DATA=<iq id="5610027" from="2960-6@chat.mysite.com" to="muc.chat.mysite.com" type="get" xmlns="jabber:client"><query xmlns="http://jabber.org/protocol/disco#items"/></iq>, SIZE=181, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=AUTH, TYPE=get

and this is server response:

log.log(Level.INFO, "MUC result: " + result);
writer.write(result);

...

2014-06-11 12:25:09.466 [in_0-muc]         DiscoItemsModule.process()         INFO:     MUC result: from=muc.chat.mysite.com, to=sess-man@ip-10-16-235-20.ec2.internal, DATA=<iq id="5610027" from="muc.chat.mysite.com" to="2960-6@muc.chat.mysite.com" xmlns="jabber:client" type="result"><query xmlns="http://jabber.org/protocol/disco#items"><item name="newmucroom1" jid="newmucroom1@muc.chat.mysite.com"/><item name="testroom" jid="testroom3@muc.chat.mysite.com"/ ... , SIZE=3303, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=result

So, everything looks great, but client's application doesn't receive this response by some reason.

When I add resource to disco#items query, e.g. from="2960-6@chat.mysite.com/iOS - everything works great.

Same for disco#info query to room.

Can you please comment this


Replies (9)

Added by Wojciech Kapcia TigaseTeam almost 5 years ago

This is a result of changes in Tigase Server from over a year ago: Changed logic for packet delivery :

Changed logic for packet delivery, both message delivery and default packet handler to intercept IQ without a dedicated plugin, the new logic deals with full JID 'to' address, it now, either delivers the packet to the correct (and only correct) resource or returns an error - recipient not available, if the message is for the bare JID it is delivered to all available resources, for the IQ to bare JID - feature not implemented is returned from the default packet handler, fixes #688 and fixes #189 for messages and default packet handler

And because you are sending message with present "from" Tigase doesn't append from (in the FullJID) from on behalf of the user hence when MUC component receives packet it's from BareJID and responds to such address, which in turn prevents message from being delivered.

All in all - either use FullJID (with resource) or don't include JID at all.

(1)

Added by Igor Khomenko almost 5 years ago

Thanks for this explanation, I will update our client app

But can we do something on the server side?

For example if lots of clients already use old Tigase. For example remove 'from' attribute from 'iq' packet on server side before processing

Added by Wojciech Kapcia TigaseTeam almost 5 years ago

Igor Khomenko wrote:

But can we do something on the server side?

I've created related ticket: #2003

(1)

Added by Igor Khomenko almost 5 years ago

I see Artur changed something

how can I check his commit?

(1)

Added by Wojciech Kapcia TigaseTeam almost 5 years ago

The only way is to go through the repository history trying to find the commit.

Added by Igor Khomenko almost 5 years ago

@Wojciech, I did some code investigation and realised that in this case I get an IQ error RECIPIENT_UNAVAILABLE from class XMPPProcessorAbstract*, *processToUserPacket method

What I did is replaced

if ((resource == null) && (packet.getElemName() == Message.ELEM_NAME)) {

with

 if ((resource == null) && (packet.getElemName() == Message.ELEM_NAME || packet.getElemName() == Iq.ELEM_NAME)) {

After this disco#items and disco#info started working for BareJID

Could it be a solution for me or this can cause some bad repercussions ?

(1)

Added by Igor Khomenko almost 5 years ago

I would like to ask more general question here:

Why don't use this code if there is no resource in JID:

List<XMPPResourceConnection> conns    = new ArrayList<XMPPResourceConnection>(5);
if (resource == null) {
     conns.addAll(session.getActiveSessions());
}

Could you please explain a bit

(1)
Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 5 years ago

It does not make any sense to process IQ stanzas this way. By definition IQ packets (info-query) work as: request -> response. It is required to deliver a response to the entity which issues the query for the response. I do not remember exact wording from the RFC but as far as I remember it is not even allowed to deliver IQ response to incorrect resource or to all resources. Therefore, if there is no resources in the IQ request, there is no way we can guarantee response delivery to a correct user's connection.

However, it is also said in the RFC that the server must ensure that the stanza sent from a client has a correct from address (including resource). If the from address is incorrect, the server should either reject the stanza or replace from with a correct JID. There is, however, exception to presence subscriptions which should contain BareJID instead, in the from address. So Tigase does not replace from address with full JID if the existing from matches user's BareJID. And I think this is incorrect. It should replace all messages and IQ with user's full JID regardless what is set in the stanza. For presences the logic should depend on the presence type.

(1)

Added by Igor Khomenko almost 5 years ago

Thanks Artur, it's clear

One thing that prevent us to just fix this on client side is that we have some old applications version where users already use this query.

That's why I think about some server alternatives.

Anyway, right now I have a clear view of what is going on. Thanks for this

    (1-9/9)