I’m using bookmarks (XEP-0048) to automatically join several MUC rooms. This works fine, when only using one single resource/client, say resource “A”. But with Openfire 3.6.0 a participant is kicked from MUC, if the same account connects from another resource (say “B”) with the same nickname. When using Psi 0.12, the resource “A” gets kicked by the server:
(When pressing “Ok” resource “B” gets also kicked, but that’s not important here.)
This is a bug in Openfire? XEP says nothing about kicking users from the room in case of an nickname conflict!
XEP-0045: Multi-User Chat
7.1.10 Nickname Conflict
If the room already contains another user with the
nickname desired by the user seeking to enter the room (or if the
nickname is reserved by another user on the member list), the service
MUST deny access to the room and inform the user of the conflict; this
is done by returning a presence stanza of type “error” specifying a
error condition:
> Example 29. Service Denies Access Because of Nick Conflict
> <presence
> from='darkcave@chat.shakespeare.lit'
> to='hag66@shakespeare.lit/pda'
> type='error'>
> <x xmlns='http://jabber.org/protocol/muc'/>
> <error type='cancel'>
> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
> </error>
> </presence>
However, if the bare JID localpart@domain.tld of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room “sessions” with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it SHOULD route in-room messages to all of the user’s resources and allow all of the user’s resources to send messages to the room; it is up to the implementation to determine how to appropriately handle presence from the user’s resources and how to route private messages to all or only one resource (based on presence priority or some other algorithm).
How nickname conflicts are determined is up to the implementation (e.g., whether the service applies a case folding routine, a stringprep profile such as Resourceprep or Nodeprep, etc.).
However, it will take probably some time until this is fixed. Is there a simple way to restore the old behavior of Openfire 3.5.x? Openfire 3.5.x simply denies connection to the MUC room, if there is already someone with the same nickname.
I used the following workaround to see if the nickname exists BEFORE sending a Presence packet and kicking the first instance.
Just pass the users Jid, e.g.: chatroom@a-conference.com/nickname and it will tell you if it exists in m_chat (MultiUserChat) using XMPPConnection m_connection:
As i have mentioned on the ticket i had some issues when trying to use the latest version this morning. I see you’ve done another commit. If it changes something i can try again ths evening.
Looks like Spark handles this scenario somewhat differently than the other clients I tested (Pidgin, Psi), but the feature seems to be working more or less as expected. I made a few additional observations in the ticket.
You were right Tom. Spark behaves differently and i don’t think it is right behavior, so i have filed a bug SPARK-1580.
Testing the latest changes. Exiting seem ok with many clients. Other resources still stay in the room and receives messages.
Daryl said prosody developers shared their ideas about implementing other vague parts of the XEP. Would be interesting to know how they handle presence and private messages. Maybe we can do the same or think of our way.
In my testing it seems that presence is always set to the latest presence change (e.g. if both resources are Online and one changes to Away, then other participants will see it as away, if another resources changes to DND, all will see it as DND, etc.). I’m not sure about this, but i can’t think of a way to handle it. Say you change your status to DND, but the other resource idles out and changes it to away. So you are not DND anymore, when you probably still want to be DND on that resource. Probably it depends on the usage scenario for this.
Private messages are sent to all resources. So if you are having a private chat with someone on one resources, when you get back to another resource, you will see a bunch of incoming private messages, but not the outgoing messages of course. Wonder if it can detect which resource has actually replied and route all subsequent messages just ot that resource. Probably not possible as both will have same JID and nickname (well, different JID+resource).
