Multiple players with the same nickname in a chat room

Openfire
1

Hi,
We are experiencing an issue where multiple users with the same nickname are allowed to join the same chat room. Since this is not allowed in the XMPP specification, we believe that this is an issue with Openfire implementation. The problem arises because each node of the Openfire cluster does not have an up-to-date list of occupants and so when a user joins with a nickname that already exists in the room, on a different node to where the original user connected, the node does not know about the occupant that already has that nickname and then allows the new player into the room.
Openfire version 4.5.2
2 nodes per cluster

2

For information, this is XMPP spec link showing that it should deny the second user: https://xmpp.org/extensions/xep-0045.html#enter-conflict

3

Thanks for reporting this. You’re right, that should not happen. There’s an issue in the clustering implementation that can cause this behavior. We’re planning to re-implement that bit of the code as part of issue OF-2219.

For the time being, you’ll need to run non-clustered to avoid this particular issue. Version 4.6.3 of Openfire (released yesterday) adds functionality to remove ‘ghost’ users from chatrooms, which might help a little - but it’s far from a fixed issue.

4

Thanks guus. Running non-clustered isn’t really an option for us as that would be a single point of failure and more difficult to persist our data.
Do you have a rough timeframe for when this will be done?
Thanks,
Michael

5

I expect to start working on this in two to four weeks. It will be at least various weeks after that, maybe months, before work will be completed.

You appear to be affiliated to a development organisation that does largish things, given the reservations you expressed in regards to not running clustered. Are you in a position where you can consider helping with getting this implemented? More resources means more faster and more better development, and we’re always on the lookout for developers that we can lure to the dark side. We’ve got cookies.

1 Like
6

Hi guus, an update from my side. We are looking at the various options we have, which includes helping you to get this implemented faster. We are currently working on something that might help on our side so that will influence our decision in the coming week or so.
I’ll let you know if we end up wanting to speed this process up by helping out.
Thanks,
Michael

1 Like
7

As an aside: we’re well on our way to re-implement MUC and clustering. The current head of both the Openfire as well as the Hazelcast plugin repositories reflect these changes. Feedback very welcome!

1 Like