ejabberd development
  1. ejabberd development
  2. EJAB-305

Allow multiple entry with same nick to MUC rooms

    Details

      Description

      XEP-0045, section 7.2.9 http://xmpp.org/extensions/xep-0045.html#enter-conflict

      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 MUST 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 whether to route private messages to all resources or only one resource (based on presence priority or some other algorithm); however, it is RECOMMENDED to route to all resources.

      Reported problems in the patch and their status:

      • A private message sent from any participant to the nick is only sent to the last joined resource. It should be sent to all the resources.
      • If the last joined resource now leaves the room, then all other resources are kicked of the room. They should be kept alive.
      • The option max_user_conferences only works correctly when the limit is 1. If the limit is 2 or more, then the user can join as many resources as he wants.
      • The option max_users is implemented in such way that it considers the multiple resources as only 1 participant.
      • Update the patch to ejabberd master branch and test it again.
      1. mod_muc_room.erl.patch
        10 kB
        Magnus Henoch
      2. mod_muc_room.erl-svn.patch
        17 kB
        Badlop
      3. mod_muc_room.erl-svn.patch
        11 kB
        Badlop
      4. mod_muc_room.erl-svn.patch
        11 kB
        Badlop
      5. mod_muc_room.erl-svn.patch
        11 kB
        Badlop
      6. mod_muc_room.erl-svn.patch
        10 kB
        Magnus Henoch

        Issue Links

          Activity

          Hide
          Magnus Henoch
          added a comment -

          This patch is running on jabber.se since a few months.

          Show
          Magnus Henoch
          added a comment - This patch is running on jabber.se since a few months.
          Hide
          Mickaël Rémond
          added a comment -

          I will be reviewing the patch, hoping it will added to ejabberd 2.0.

          Show
          Mickaël Rémond
          added a comment - I will be reviewing the patch, hoping it will added to ejabberd 2.0.
          Hide
          Mickaël Rémond
          added a comment -

          By the way, do you know if it apply directly against trunk ?

          Show
          Mickaël Rémond
          added a comment - By the way, do you know if it apply directly against trunk ?
          Hide
          Magnus Henoch
          added a comment -

          No, but this one does; compiled but not tested.

          Show
          Magnus Henoch
          added a comment - No, but this one does; compiled but not tested.
          Hide
          Mickaël Rémond
          added a comment -

          The main problem with this feature is that it simplifies denial of service: You will be able to connect as many time as you want to a chatroom and provoque massive broadcast of messages / presence.
          We should have an option to limit the max number of connexions in the same room for a given user (integer > 0).

          Maybe we should implement it as a kind of "login replaced" (analogy to "connection replaced") ?
          The use case for this is to be able to join a chatroom with your nick even if you have your client opened on another computer, logged into the same room.
          If you try to rejoin one more time the correct behaviour could be:

          • Replace the full JID corresponding to the nick with the new one (if the bare JID is the same).
          • Send to the previous full JID an information stating that it has been replaced in the room by the new resource.
          • Find a mechanism to broadcast the new full JID in the room (like a presence update), if the room allow to see actual JID and only for users that can see this actual JID.

          What do you think ?

          Show
          Mickaël Rémond
          added a comment - The main problem with this feature is that it simplifies denial of service: You will be able to connect as many time as you want to a chatroom and provoque massive broadcast of messages / presence. We should have an option to limit the max number of connexions in the same room for a given user (integer > 0). Maybe we should implement it as a kind of "login replaced" (analogy to "connection replaced") ? The use case for this is to be able to join a chatroom with your nick even if you have your client opened on another computer, logged into the same room. If you try to rejoin one more time the correct behaviour could be: Replace the full JID corresponding to the nick with the new one (if the bare JID is the same). Send to the previous full JID an information stating that it has been replaced in the room by the new resource. Find a mechanism to broadcast the new full JID in the room (like a presence update), if the room allow to see actual JID and only for users that can see this actual JID. What do you think ?
          Hide
          Magnus Henoch
          added a comment -

          I think being able to be in a chatroom from several places at once is the major point of this change, so I'd rather have that stay; I usually stay in lots of chatrooms even when I leave my computer, and sometimes want to enter them briefly from another computer without disrupting the accumulated history at home, and without having to have my home client rejoin in some way.

          Having a limit for the number of sessions for a single user might make sense, though...

          Show
          Magnus Henoch
          added a comment - I think being able to be in a chatroom from several places at once is the major point of this change, so I'd rather have that stay; I usually stay in lots of chatrooms even when I leave my computer, and sometimes want to enter them briefly from another computer without disrupting the accumulated history at home, and without having to have my home client rejoin in some way. Having a limit for the number of sessions for a single user might make sense, though...
          Hide
          Jérôme Sautret
          added a comment -

          We need the limit on the number of sessions for a single user before adding this feature.

          Show
          Jérôme Sautret
          added a comment - We need the limit on the number of sessions for a single user before adding this feature.
          Hide
          eharris
          added a comment -

          I agree that the ability to have multiple active connections to a room definitely needs to stay/be added.

          I commonly run a jabber client on several computers, and having the history on all of them is pretty much a necessity. I've applied this patch to my server, and it seems to work, although there seem to be a few problems relating to room connections going stale when multiply logged in AND I've said something from more than one of those connections. But I'm not entirely sure they aren't client related (pidgin). There's also a problem with the room occupants list sometimes being empty when refreshing a stale connection, but again I'm not sure that isn't a pidgin problem.

          Show
          eharris
          added a comment - I agree that the ability to have multiple active connections to a room definitely needs to stay/be added. I commonly run a jabber client on several computers, and having the history on all of them is pretty much a necessity. I've applied this patch to my server, and it seems to work, although there seem to be a few problems relating to room connections going stale when multiply logged in AND I've said something from more than one of those connections. But I'm not entirely sure they aren't client related (pidgin). There's also a problem with the room occupants list sometimes being empty when refreshing a stale connection, but again I'm not sure that isn't a pidgin problem.
          Hide
          eharris
          added a comment -

          After reviewing the changelogs for recent releases since this issue was opened, it seems there are several issues that have been fixed in 2.0.0 regarding implementation of limits to prevent DOS problems. So hopefully that sufficiently allays those concerns so that this patch can be included in the earlier 2.0.2 rather than delaying for 2.1 or later?

          Show
          eharris
          added a comment - After reviewing the changelogs for recent releases since this issue was opened, it seems there are several issues that have been fixed in 2.0.0 regarding implementation of limits to prevent DOS problems. So hopefully that sufficiently allays those concerns so that this patch can be included in the earlier 2.0.2 rather than delaying for 2.1 or later?
          Hide
          Badlop
          added a comment -

          I've updated the SVN patch to work against current trunk SVN. There were a few collisions that require manual merging.

          The current version of XEP45 says:

          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).

          During the tests I found several problems:

          • A private message sent from any participant to the nick is only sent to the last joined resource. It should be sent to all the resources.
          • If the last joined resource now leaves the room, then all other resources are kicked of the room. They should be kept alive.
          • The option max_user_conferences only works correctly when the limit is 1. If the limit is 2 or more, then the user can join as many resources as he wants.
          • The option max_users is implemented in such way that it considers the multiple resources as only 1 participant.
          Show
          Badlop
          added a comment - I've updated the SVN patch to work against current trunk SVN. There were a few collisions that require manual merging. The current version of XEP45 says: 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). During the tests I found several problems: A private message sent from any participant to the nick is only sent to the last joined resource. It should be sent to all the resources. If the last joined resource now leaves the room, then all other resources are kicked of the room. They should be kept alive. The option max_user_conferences only works correctly when the limit is 1. If the limit is 2 or more, then the user can join as many resources as he wants. The option max_users is implemented in such way that it considers the multiple resources as only 1 participant.
          Hide
          Stephan
          added a comment -

          this is still not implemented in current svn, the patch applies with only one hunk failing, which is because some of the stuff that it tries to patch has been moved to a .hrl file. would be nice to see this moved upstream.

          Show
          Stephan
          added a comment - this is still not implemented in current svn, the patch applies with only one hunk failing, which is because some of the stuff that it tries to patch has been moved to a .hrl file. would be nice to see this moved upstream.
          Hide
          Mickaël Rémond
          added a comment -

          Hello Stephan,

          We have even more change ready for 3.0.
          It can only be made upstream after 3.0 version to avoid duplicate work.

          Show
          Mickaël Rémond
          added a comment - Hello Stephan, We have even more change ready for 3.0. It can only be made upstream after 3.0 version to avoid duplicate work.
          Hide
          Stephan
          added a comment -

          awesome, i will wait patiently and use the patch during that time...thanks for the quick answer.

          Show
          Stephan
          added a comment - awesome, i will wait patiently and use the patch during that time...thanks for the quick answer.
          Hide
          Badlop
          added a comment -

          I've updated the patch to apply correctly to latest SVN trunk and 2.1.0-beta2

          However, the patch still has the problems I described in a previous comment.

          Show
          Badlop
          added a comment - I've updated the patch to apply correctly to latest SVN trunk and 2.1.0-beta2 However, the patch still has the problems I described in a previous comment.
          Hide
          Neustradamus
          added a comment - - edited

          In 3.1.0 ? It is a serious problem, can you correct before ?

          From : https://support.process-one.net/browse/EJAB-1099

          There is a problem when I log on the same room (same JID) with 2 computers (or other).
          http://xmpp.org/extensions/xep-0045.html#enter-conflict

          Show
          Neustradamus
          added a comment - - edited In 3.1.0 ? It is a serious problem, can you correct before ? From : https://support.process-one.net/browse/EJAB-1099 There is a problem when I log on the same room (same JID) with 2 computers (or other). http://xmpp.org/extensions/xep-0045.html#enter-conflict
          Hide
          Neustradamus
          added a comment - - edited

          This patch https://support.process-one.net/secure/attachment/14936/mod_muc_room.erl-svn.patch works with same JID+different ressource / not work with different JID+different ressource (so it is good).
          Can you add in SVN ?

          After if there are problems, it is client problems.

          I have an idea, you can add an option in room setting for enable/disable Multiple JID connection.

          Show
          Neustradamus
          added a comment - - edited This patch https://support.process-one.net/secure/attachment/14936/mod_muc_room.erl-svn.patch works with same JID+different ressource / not work with different JID+different ressource (so it is good). Can you add in SVN ? After if there are problems, it is client problems. I have an idea, you can add an option in room setting for enable/disable Multiple JID connection.
          Hide
          Stephan
          added a comment -

          we are using the patch in the last comment and wa are having weitd problems with messages that are being sent to ressources that they do not belong to (and are not adressed to). this leads to messages being shown multiple times in one room that i joined with different ressources. could this be a problem with this patch or are we onto something completely different here?

          Show
          Stephan
          added a comment - we are using the patch in the last comment and wa are having weitd problems with messages that are being sent to ressources that they do not belong to (and are not adressed to). this leads to messages being shown multiple times in one room that i joined with different ressources. could this be a problem with this patch or are we onto something completely different here?
          Hide
          Badlop
          added a comment -

          we are using the patch in the last comment and wa are having weitd problems ... could this be a problem with this patch or are we onto something completely different here?

          Only you can know the answer: install ejabberd unpatched and try to reproduce that problem. If the problem disappears, then it probably is a problem related to the patch.

          Show
          Badlop
          added a comment - we are using the patch in the last comment and wa are having weitd problems ... could this be a problem with this patch or are we onto something completely different here? Only you can know the answer: install ejabberd unpatched and try to reproduce that problem. If the problem disappears, then it probably is a problem related to the patch.
          Hide
          louiz'
          added a comment -

          This patch doesn't work on ejabberd 2.1.2 (applies but doesn't compile).
          Also, the last time I checked, it didn't work properly : you can join a room with the same nick and it's ok, but when one of the clients leaves the room, the other one is ejected (not really kicked because you don't have any message).

          Show
          louiz'
          added a comment - This patch doesn't work on ejabberd 2.1.2 (applies but doesn't compile). Also, the last time I checked, it didn't work properly : you can join a room with the same nick and it's ok, but when one of the clients leaves the room, the other one is ejected (not really kicked because you don't have any message).
          Hide
          Badlop
          added a comment -

          This patch doesn't work on ejabberd 2.1.2 (applies but doesn't compile).

          The patch applies and compiles correctly using ejabberd 2.1.x

          when one of the clients leaves the room, the other one is ejected

          I already pointed this problem in a previous comment.

          Show
          Badlop
          added a comment - This patch doesn't work on ejabberd 2.1.2 (applies but doesn't compile). The patch applies and compiles correctly using ejabberd 2.1.x when one of the clients leaves the room, the other one is ejected I already pointed this problem in a previous comment.
          Hide
          eharris
          added a comment -

          Just curious, is there a reason this is tagged to be fixed in 3.1.0 rather than the upcoming 3.0?

          Show
          eharris
          added a comment - Just curious, is there a reason this is tagged to be fixed in 3.1.0 rather than the upcoming 3.0?
          Hide
          Badlop
          added a comment -

          I've uploaded a new patch updated to recent ejabberd 2.1.x, and it maybe fixes those problems:

          • A private message sent from any participant to the nick is only sent to the last joined resource. It should be sent to all the resources.
          • If the last joined resource now leaves the room, then all other resources are kicked of the room. They should be kept alive.
          • The option max_user_conferences only works correctly when the limit is 1. If the limit is 2 or more, then the user can join as many resources as he wants.
          • The option max_users is implemented in such way that it considers the multiple resources as only 1 participant.

          People interested in this ticket: try the patch and report if those problems are fixed, and what other problems are there.

          Show
          Badlop
          added a comment - I've uploaded a new patch updated to recent ejabberd 2.1.x, and it maybe fixes those problems: A private message sent from any participant to the nick is only sent to the last joined resource. It should be sent to all the resources. If the last joined resource now leaves the room, then all other resources are kicked of the room. They should be kept alive. The option max_user_conferences only works correctly when the limit is 1. If the limit is 2 or more, then the user can join as many resources as he wants. The option max_users is implemented in such way that it considers the multiple resources as only 1 participant. People interested in this ticket: try the patch and report if those problems are fixed, and what other problems are there.
          Hide
          Tomasz Kraus
          added a comment -

          Hello, is there any configuration needed after applying and recompiling ejabberd 2.1.8 ??

          When i connect with strophe.js in many tabs with same JID and same resource I get HTTP 404s, and ejabberd log also claims the session is getting replaced:

          {{{
          =INFO REPORT==== 17-Aug-2011::10:27:45 ===
          I(<0.475.0>:ejabberd_c2s:767) : ({socket_state,ejabberd_http_bind,{http_bind,<0.474.0>,127,0,0,1},46922,ejabberd_http_bind}) Accepted authentication for Balrog by ejabberd_auth_anonymous

          =INFO REPORT==== 17-Aug-2011::10:27:46 ===
          I(<0.475.0>:ejabberd_c2s:890) : ({socket_state,ejabberd_http_bind,{http_bind,<0.474.0>,127,0,0,1},46922,ejabberd_http_bind}) Opened session for Balrog@hmwrk.lh/pm

          =INFO REPORT==== 17-Aug-2011::10:27:46 ===
          I(<0.472.0>:ejabberd_c2s:1435) : ({socket_state,ejabberd_http_bind,{http_bind,<0.471.0>,127,0,0,1},46872,ejabberd_http_bind}) Replaced session for Balrog@hmwrk.lh/pm
          }}}

          Show
          Tomasz Kraus
          added a comment - Hello, is there any configuration needed after applying and recompiling ejabberd 2.1.8 ?? When i connect with strophe.js in many tabs with same JID and same resource I get HTTP 404s, and ejabberd log also claims the session is getting replaced: {{{ =INFO REPORT==== 17-Aug-2011::10:27:45 === I(<0.475.0>:ejabberd_c2s:767) : ({socket_state,ejabberd_http_bind,{http_bind,<0.474.0>, 127,0,0,1},46922 ,ejabberd_http_bind}) Accepted authentication for Balrog by ejabberd_auth_anonymous =INFO REPORT==== 17-Aug-2011::10:27:46 === I(<0.475.0>:ejabberd_c2s:890) : ({socket_state,ejabberd_http_bind,{http_bind,<0.474.0>, 127,0,0,1},46922 ,ejabberd_http_bind}) Opened session for Balrog@hmwrk.lh/pm =INFO REPORT==== 17-Aug-2011::10:27:46 === I(<0.472.0>:ejabberd_c2s:1435) : ({socket_state,ejabberd_http_bind,{http_bind,<0.471.0>, 127,0,0,1},46872 ,ejabberd_http_bind}) Replaced session for Balrog@hmwrk.lh/pm }}}
          Hide
          Badlop
          added a comment -

          Tomasz Kraus: this ticket is about MUC nick conflict. If you refer to XMPP resource conflict, see New option resource_conflict to define server action.

          Show
          Badlop
          added a comment - Tomasz Kraus: this ticket is about MUC nick conflict. If you refer to XMPP resource conflict, see New option resource_conflict to define server action .
          Hide
          Badlop
          added a comment -

          I've migrated the patch to ejabberd master, and tested it. I've applied the patch to branches 2.1.x and master.

          Show
          Badlop
          added a comment - I've migrated the patch to ejabberd master, and tested it. I've applied the patch to branches 2.1.x and master.
          Hide
          Vitaly Takmazov
          added a comment -

          Minor inconsistence after applying this patch:
          1) User enter to room with client 1, muc generate presence with "client 1"'s capabilities
          2) User enter to room with client 2, muc generate presence with "client 2"'s capabilities
          3) User leave room from client 2, muc do not generate presence, so we have "client 2" capabilities, but only "client 1" present.

          Possible solution: muc should need to generate presence from "client 1" when client 2 leave room.

          Show
          Vitaly Takmazov
          added a comment - Minor inconsistence after applying this patch: 1) User enter to room with client 1, muc generate presence with "client 1"'s capabilities 2) User enter to room with client 2, muc generate presence with "client 2"'s capabilities 3) User leave room from client 2, muc do not generate presence, so we have "client 2" capabilities, but only "client 1" present. Possible solution: muc should need to generate presence from "client 1" when client 2 leave room.
          Hide
          Badlop
          added a comment -

          Vitaly: this ticket was about improvimg MUC to allow multiple entry with same nick to MUC rooms. ejabberd already implements that. This ticket is closed.

          What you describe is a problem, or a bug. Open a new ticket for that. And provide a patch if you can.

          Show
          Badlop
          added a comment - Vitaly: this ticket was about improvimg MUC to allow multiple entry with same nick to MUC rooms. ejabberd already implements that. This ticket is closed. What you describe is a problem, or a bug. Open a new ticket for that. And provide a patch if you can.

            People

            • Votes:
              4 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                2 years, 33 weeks, 2 days ago

                Issue deployment