My team and I noticed, what we thought was, an odd reaction by Openfire when clients send messages to another with resources that do not exist. Instead of killing the message, Openfire appears to send the message to the resource that was the last to login.
To put it a different way.
UserA logs in with resource A1
UserA logs in somewhere else with resource A2
UserB logs in with resource B1
UserB sends message to UserA, both A1 and A2 receive the message
UserB sends message to UserA/A1, only A1 receives the message
UserB sends message to UserA/A4, UserA/A2 receives the message and UserA/A1 does not receive the message
UserB sends message to UserA/Fault, UserA/A2 receives the message and UserA/A1 does not receive the message
From my understanding of the XMPP standard, this should not be happening. The point of the resources is so that messages to a specific resource only go to that resource. Thus, when a message is sent to a resource that does not exist, shouldn’t that message die? If this is not the case, what code in Openfire do I need to modify in order to change this? In other words, how do I stop this from happening so that if the resource does not exist, the message dies? The way in which we are integrating openfire into our system requires messages / stanzas that are not addressed properly (i.e. incorrect / non-existant resources) MUST die.
Thanks.
KMC
1 Like
This is the correct behaviour as defined in the spec (http://xmpp.org/rfcs/rfc6120.html#rules-local). The relevant excerpt is as follows.
10.5.4. localpart@domainpart/resourcepart
If the JID contained in the ‘to’ attribute is of the form <localpart@domainpart/resourcepart> and the user exists but there is no connected resource that exactly matches the full JID, the stanza SHOULD be processed as if the JID were of the form localpart@domainpart as described under Section 10.5.3.2.
If the JID contained in the ‘to’ attribute is of the form <localpart@domainpart/resourcepart>, the user exists, and there is a connected resource that exactly matches the full JID, the server MUST deliver the stanza to that connected resource.
One option to override this behaviour would be to create a plugin with a PacketInterceptor to check the to address. This would not require any customization of the server itself.
Ah, I did not know about that specification. That explains the behavior.
However, I think Openfire might still have a bug as messages sent to "usera@domiain.com/bogus-resource" did not map and get routed to "usera@domain.com". Instead, it only went to the newest connection of usera. That is, if usera first logged in as "usera@domain.com/resource1" and then at another location as "usera@domain.com/resource2", the message was only sent to "usera@domain.com/resource2" and not to "usera@domain.com/resource1".
And thank you for the suggestion, we have taking a look at it and it sounds like it has been successfully implemented.
Thanks again.