Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Prevent potential nickname clashes when occupants of clustered MUC room are merged.

Description

When a new cluster node is joining the cluster, its MUC room state is merged with that of the same rooms in the cluster.

There can be a scenario where the joining node has an occupant that uses a nickname, for which the nickname is already in use by a different occupant on another node. The existing implementation does not handle this (and will simply overwrite internal state of Openfire). Instead, proper handling (that likely involves communication to a client) needs to be implemented.

Note that a related, but distinct scenario is where each cluster node has a different occupant, but that those represent two different resources of the same end-user (Multi-Session nicks).

Environment

None

Activity

Show:

Guus der Kinderen November 2, 2021 at 8:53 AM

From all servers' POV, there are 2 occupants - the 2 users, both with the same nickname.

That sounds like an illegal room configuration - as in: not allowable by the XEP.

Dan Caseley November 1, 2021 at 11:11 PM

Thus far, we haven’t attempted to fix this. Testing backs this up

 

2 clients logged in as 2 different users on 2 nodes that cannot communicate join the same MUC (or server-local representation thereof) using the same nickname.

When the cluster comms are restored, the cluster state is merged. From the clients' POV, the MUC has 1 occupant. From all servers' POV, there are 2 occupants - the 2 users, both with the same nickname. Any message sent from either client (both JSXC) appears in both clients as coming from themselves.

Dan Caseley September 5, 2021 at 5:55 PM

There may not be a XEP-0045 compliant way to communicate this to a client, since nick conflict resolution is only specified for join time. It may require a kick to one of the conflicted users.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Priority

Created December 21, 2020 at 1:48 PM
Updated November 22, 2021 at 11:39 AM
Resolved November 22, 2021 at 11:39 AM