Message goes to someone outside toJID

When this happens I can’t find any log. I am using the monitoring plugin and I see that the message fromJID and toJID values are correct. For example, let’s suppose that 3 people are online on openfire. 1@openfire, 2@openfire, 3@openfire
1@openfire 2@openfire sends a message and this is the message package she sends:

<message
    from="1@openfire/web"
    to="2@openfire"
    type="chat"
    id="05f3ac4a-d766-4cdb-dd3c-0e21e782d8e0"
    xmlns="jabber:client">
    <body>
        hello 2
    </body>
    <request xmlns="urn:xmpp:receipts">
    </request>
</message>

In this case, while 2@openfire sessions should receive a message, 3@openfire receives the following message:

<message
    from="1@openfire/web"
    to="2@openfire"
    type="chat"
    id="05f3ac4a-d766-4cdb-dd3c-0e21e782d8e0"
    xmlns="jabber:client">
    <body>
        hello 2
    </body>
    <request xmlns="urn:xmpp:receipts">
    </request>
</message>

We are using Bosh. We use an openfire with about 400 people online. The problem I mentioned occurs every 2-3 months. Something that is not continuous. But this problem causes serious misunderstanding. This problem made me think that the sessions on the openfire side are statically managed, but I don’t know whether or not it is true.

That’s an issue of concern. What version of Openfire are you using? What clients are involved? Does this occur with ‘live’ messages, or does this occur with messages retrieved from an archive (or both)? How do your clients connect to Openfire? Is there any custom code involved?

We are using 4.6.0, but it was also seen when using 4.5.2.

What clients are involved?

3 people have been affected so far. username values: 118, 220, 184, 486, 31, 408, 252, 315, 392

Examples:
from: 118, to: 220 (the person receiving the message is 315)
from: 184, to: 486 (the person receiving the message 392)
from: 31, to: 408 (the person receiving the message is 252)

All of these people were online and did not retrieve messages from the archive

Does this occur with ‘live’ messages, or does this occur with messages retrieved from an archive (or both)?

It only goes live. It is recorded absolutely correctly in archive (monitoring plugin ofMessageArchive).

How do your clients connect to Openfire? Is there any custom code involved?

We use a plugin to capture the user’s messages and send push notifications. We naturally use PacketInterceptor in that plugin. We read the incoming package without changing any content and send push notifications accordingly. We use PresenceEventListener to keep track of people’s entry and exit, in the same way we only read the incoming packages. We change the authorization layer (i.e. provider.auth.className and provider.user.className) and use our own validation method.

Are you able to reproduce the issue when the plugin is unloaded?

Unfortunately, it is not possible for me to uninstall the plugin and try it. As I said, I cannot demo this because it happens every 2-3 months.

When you’re saying that you’re using custom code, keeping in mind that no-one else reported a similar issue, then that code becomes a likely suspect. Without steps to reproduce the problem, it’s hard to diagnose the issue. Maybe you can write a packet interceptor that records the ‘to’ addresses of outbound stanzas, and verify that it corresponds with the user that it is being delivered to? If it’s not the case, you could log a stacktrace, or other diagnostic data. Perhaps that will reveal a cause.

1 Like