processone / ejabberd

Robust, Ubiquitous and Massively Scalable Messaging Platform (XMPP, MQTT, SIP Server)
https://www.process-one.net/ejabberd/
Other
6.11k stars 1.51k forks source link

MucSub affiliation changes #4032

Open dkliss opened 1 year ago

dkliss commented 1 year ago

Hi, this issue has been discussed in link below but has been closed. However, looks like it has not been resolved.

https://github.com/processone/ejabberd/issues/3172

What I tried.

Scenario 1: There is a room, with three participants. One of three participants is an Owner. Remaining are only members. If Owner, makes one of the member as Admin, the Owner receive a response from server on affiliation change, but member does not receive anything.

Scenario 2: The room has three members and this time one is Owner, One is Admin, and other is Member. This time, Owner, made an Admin to be a member. And the Admin user, even though an Admin does not receive any response on Affiliation Change.

Summary In summary:

  1. Only "Owner" Receives a Iq Result Stanza of Affiliation Change.
  2. Neither Admin nor Member receives any Iq Stanza Affiliation Change.
  3. Question: Can this is considered a Bug or is this an expected result for some reason?

Optional Information

Example test scenarios are below.

Scenario 1: Owner changes Member To Admin. Owner receives Result. Member Receives Nothing. Expected: Member is informed of Affiliation Change.

SENT BY OWNER:
<iq id="KTGEWXDTJ" type="set" from="ownerNick@testServer.com/69cc4690-f06d-11ed-a32a-85ca8676ac7f" 
to="mucSubRoom@conference.testServer.com"><query xmlns="http://jabber.org/protocol/muc#admin"><item 
affiliation="admin" jid="otherUserNick@testServer.com"><reason>Changing Affiliation Status </reason></item></query></iq>

RECEIVED ONLY BY OWNER:
<iq xml:lang='en' to='ownerNick@testServer.com/69cc4690-f06d-11ed-a32a-85ca8676ac7f' 
from='mucSubRoom@conference.testServer.com' type='result' id='KTGEWXDTJ'/>

Scenario 2: Owner changes Admin to Member. Owner receives Result. Member Receives Nothing Expected: Member is informed of Affiliation Change.

SENT BY OWNER:
<iq id="PURPXJXIO" type="set" from="ownerNick@testServer.com/69cc4690-f06d-11ed-a32a-85ca8676ac7f" 
to="mucSubRoom@conference.testServer.com"><query xmlns="http://jabber.org/protocol/muc#admin"><item 
affiliation="member" jid="otherUserNick@testServer.com"><reason>Changing Affiliation Status </reason></item></query>
</iq>

RECEIVED ONLY BY OWNER:
<iq xml:lang='en' to='ownerNick@testServer.com/69cc4690-f06d-11ed-a32a-85ca8676ac7f' 
from='mucSubRoom@conference.testServer.com' type='result' id='PURPXJXIO'/>

Setup Users are subscribed to following nodes.

urn:xmpp:mucsub:nodes:presence
urn:xmpp:mucsub:nodes:messages
urn:xmpp:mucsub:nodes:affiliations
urn:xmpp:mucsub:nodes:subscribers
urn:xmpp:mucsub:nodes:config
urn:xmpp:mucsub:nodes:subject
urn:xmpp:mucsub:nodes:system

Note, If when changing affiliation, I also send a presence stanza (Join a Room), then I receive presence packaged in MucSub (as per example stanza in docs below), which is sent to users whose affiliation is changed. But if we did this, then we will be "Present" in room as per XEP--0045, and after that, the room will start sending standard messages instead of MUCSUB encapsulated messages i.e. below approach basically breaks MucSub

<message from="coven@muc.shakespeare.example"
         to="hag66@shakespeare.example/pda">
  <event xmlns="http://jabber.org/protocol/pubsub#event">
    <items node="urn:xmpp:mucsub:nodes:presences">
      <item id="8170705750417052518">
        <presence xmlns="jabber:client"
                  from="coven@muc.shakespeare.example/secondwitch"
                  type="unavailable"
                  to="hag66@shakespeare.example/pda">
          <x xmlns="http://jabber.org/protocol/muc#user">
            <item affiliation="none"
                  role="none" />
          </x>
        </presence>
      </item>
    </items>
  </event>
</message>

Before creating a ticket, please consider if this should fit the discussion forum better.

Environment

Configuration (only if needed): grep -Ev '^$|^\s*#' ejabberd.yml

loglevel: 4
...

Errors from error.log/crash.log

No errors

Bug description

Please, give us a precise description (what does not work, what is expected, etc.)

prefiks commented 1 year ago

What you are seeing there is probably result of a filter that we apply when room is set to anonymous. In that case we send notifications for that only to moderators (as event payload contains real jid, without this we will expose real jid of user to everyone). Possibly we could tweak this and send only nick name in that case to everyone else?

dkliss commented 1 year ago

Hi,

Nick name change indicating whose "Affiliation" is change should work. At least a recipient can adjust change of affiliation status.

Found a note from XEP. "Roles" are granted, revoked, and maintained based on the occupant's room nickname or full JID rather than bare JID. Whereas, "Affiliations" are granted, revoked, and maintained based on the user's bare JID, not the nick as with roles. So, I am assuming the nick (you mentioned) will be username within bare JID for affiliation change (and nick will be MUC Nick for "Role" change)?

On your comment " only to moderators", I am not really clear on how MucSub handles "Roles". Below is my summary but if I am missing any info, please correct me.

For Affiliations, If I am an Admin or Owner Affiliate, I can fetch list of Admins or Owners or Others from server.

For Roles, even if I have set Affiliations to Admin or Owner, I cannot get list of Roles (i.e. moderators, or participants) from the server. What I get is an error message "Moderator privileges required".

Now, I am not sure, even if when I am an Owner, if my "Role" is set up as "Moderator" in the server. This is because, when I issue a subscribe request stanza shown below, I do not see what was my role setup in server i.e. is my role = moderator. In XEP-0045, upon sending a JOIN, i receive response as affiliation=owner and role =moderator.

<iq from='hag66@shakespeare.example'
    to='coven@muc.shakespeare.example'
    type='set'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <subscribe xmlns='urn:xmpp:mucsub:0'
             nick='mynick'
             password='roompassword'>
    <event node='urn:xmpp:mucsub:nodes:messages' />
    <event node='urn:xmpp:mucsub:nodes:affiliations' />
    <event node='urn:xmpp:mucsub:nodes:subject' />
    <event node='urn:xmpp:mucsub:nodes:config' />
  </subscribe>
</iq>

However, in MucSub, I can confirm that I am an Owner via getting list of affiliates from the server. But because of error "Moderator privileges required", I cannot retrieve list of "Roles" from server and hence I am not sure If I am a "Moderator".

And to me the root cause of this seems to be, that the server has not assigned any "role" to a user who created a room (affiliation=owner). And hence, the "owner" is not setup as role=moderator and hence the owner or admins cannot really fetch list of roles from server.

This is my observation. I am not sure how to confirm, what "role" an owner is assigned when a MucSub subscribe is issued as Result does not show that. So, I was wondering, if similar to XEP-0045, a default role of "moderator" needs to be setup for affiliates "owner" .

In summary, looks like, MucSub does not support "Roles" alteration. And, not sure, if a default role for Owner can be setup as "Moderator" OR alternative, a user is provided with an option on XML stanza to set the "Role" as per their wish.

For example,

One option is, including a response in stanza below on what was the role assigned:

<iq from='hag66@shakespeare.example'
    to='coven@muc.shakespeare.example'
    type='set'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <subscribe xmlns='urn:xmpp:mucsub:0'
             nick='mynick'
             role='moderator'.  <-------THIS IS NEW
             password='roompassword'>
    <event node='urn:xmpp:mucsub:nodes:messages' />
    <event node='urn:xmpp:mucsub:nodes:affiliations' />
    <event node='urn:xmpp:mucsub:nodes:subject' />
    <event node='urn:xmpp:mucsub:nodes:config' />
  </subscribe>
</iq> 

Other option is to allow An API option for users to assign role as below:

<iq from='hag66@shakespeare.example'
    to='coven@muc.shakespeare.example'
    type='set'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <subscribe xmlns='urn:xmpp:mucsub:0'
             nick='mynick'
            role='moderator'.  <-------THIS IS NEW AND USER DEFINED
             password='roompassword'>
    <event node='urn:xmpp:mucsub:nodes:messages' />
    <event node='urn:xmpp:mucsub:nodes:affiliations' />
    <event node='urn:xmpp:mucsub:nodes:subject' />
    <event node='urn:xmpp:mucsub:nodes:config' />
  </subscribe>
</iq>

What you are seeing there is probably result of a filter that we apply when room is set to anonymous. In that case we send notifications for that only to moderators (as event payload contains real jid, without this we will expose real jid of user to everyone). Possibly we could tweak this and send only nick name in that case to everyone else?

dkliss commented 1 year ago

What you are seeing there is probably result of a filter that we apply when room is set to anonymous. In that case we send notifications for that only to moderators (as event payload contains real jid, without this we will expose real jid of user to everyone). Possibly we could tweak this and send only nick name in that case to everyone else?

Sharing some more info on the Affiliation versus Role, after some checking. The stanza for Affiliation versus Role is below. When changing Affiliation, XEP is using destination JID. Whereas when changing Role, destination is a "Nick".

AFFILIATION: EXAMPLE STANZA FOT CHANGING AFFILIATION

<iq id="MNNADLQDI" type="set" from="myTestUserJID@testServer.com/69cc4690" 
          to="mucSubRoom@conference.testServer.com">
    <query
        xmlns="http://jabber.org/protocol/muc#admin">
        <item affiliation="admin" jid="otherTestUserJID@testServer.com">. <-- THIS IS A JID
            <reason>Changing Affiliation Status </reason>
        </item>
    </query>
</iq>

ROLE: EXAMPLE STANZA FOT CHANGING ROLE 
(BELOW Responds with ERROR: Changing role/affiliation is not allowed) 
Seems related to Owner not assigned default tole of moderator. 

<iq id="MLIYDJWST" type="set" from="myTestUserJID@testServer.com/69cc4690" 
          to="mucSubRoom@conference.testServer.com">
    <query
        xmlns="http://jabber.org/protocol/muc#admin">
        <item nick="otherTestUserNick" role="moderator">.      < --THIS IS A NICK
            <reason>Changing your role</reason>
        </item>
    </query>
</iq>

Based on above, what I found is:

  1. Affiliation can be changed even if a user is not a member of the room. And I have verified this by removing a "member" from a group, changing its Affiliation from "Member" to "Admin" and then re-joining the room. The Affiliation of "member" was changed to "Admin".
  2. Role, is associated with Nick, and Nick is Only assigned when a member is in the room and therefore I doubt Role can changed when a user is not in Room (unless Nick is persistent). I cannot test this due to issues related "Moderator Privilege Required" error I am getting, which does not allow me to change roles.

Based on above, what could work is below:-

  1. For Affiliation changes, we can send notifications to username within the JID (or the JID?), because affiliation is attached to the JID.
  2. For Role changes, we can send notifications to the Nick, because roles are attached to Nick.
dkliss commented 1 year ago

Hi,

I was wondering if any update on this ? I did some further checking on semi-anonymous (JIDs to moderators only, roomconfig_whois=moderators) rooms, and affiliation changes are still not sent to anyone (including affiliate=admin). It potentially seems because of role-moderator is not used as everyone gets a role =none.

I found note below in documentation, which confirms that role = none is actually part of mucsub. I was wondering if any other way to send notifications from server side. If this is not possible because of was mucsub works, i can close this.

"Until a subscriber is not joined a conference (see Joining a MUC Room), a subscriber role MUST be 'none'."