#1272 De-registered users from members-only MUC are not being kicked from the room
Reporter
marc0s
Owner
MattJ
Created
Updated
Stars
★★ (2)
Tags
Milestone-0.11
Status-Fixed
Priority-Medium
Type-Defect
marc0s
on
What steps will reproduce the problem?
1. Juliet joins a new MUC
2. Juliet configures it members-only
3. Juliet invites Romeo
4. They both chat
5. Romeo de-registers himself from the room
What is the expected output?
6. Romeo loses its affiliation and is kicked from the room
What do you see instead?
6. Romeo loses its affiliation but stays in the room
7. Romeo can still send a message
What version of the product are you using? On what operating system?
0.11.1-1~stretch1/Debian stretch
Please provide any additional information below.
<!--
ROOM CONFIGURATION QUERY
-->
<!-- Outgoing Tue 18 Dec 2018 14:23:44 CET -->
<iq xmlns="jabber:client" from="user1@localhost" type="get" to="deregister@conference.localhost" id="ik3vs715">
<query xmlns="http://jabber.org/protocol/disco#info" />
</iq>
<!-- Incoming Tue 18 Dec 2018 14:23:44 CET -->
<iq xmlns="jabber:client" type="result" from="deregister@conference.localhost" to="user1@localhost/gajim.LC22DSJ7" id="ik3vs715">
<query xmlns="http://jabber.org/protocol/disco#info" node="">
<feature var="http://jabber.org/protocol/muc#request" />
<feature var="muc_unsecured" />
<feature var="muc_temporary" />
<feature var="muc_membersonly" />
<feature var="muc_hidden" />
<feature var="http://jabber.org/protocol/muc" />
<feature var="http://jabber.org/protocol/muc#stable_id" />
<feature var="muc_unmoderated" />
<identity type="text" name="deregister tests" category="conference" />
<feature var="muc_semianonymous" />
<feature var="jabber:iq:register" />
<x type="result" xmlns="jabber:x:data">
<field type="hidden" var="FORM_TYPE">
<value>http://jabber.org/protocol/muc#roominfo</value>
</field>
<field type="text-single" var="muc#roominfo_lang">
<value />
</field>
<field type="boolean" label="Allow members to invite new members" var="{http://prosody.im/protocol/muc}roomconfig_allowmemberinvites">
<value>0</value>
</field>
<field type="text-single" label="Title" var="muc#roomconfig_roomname">
<value>deregister tests</value>
</field>
<field type="text-single" label="Description" var="muc#roominfo_description">
<value />
</field>
<field type="boolean" var="muc#roominfo_changesubject" />
<field type="text-single" label="Number of occupants" var="muc#roominfo_occupants">
<value>2</value>
</field>
</x>
</query>
</iq>
<!--
DE-REGISTERING QUERY AND MESSAGING
-->
<!-- Outgoing Tue 18 Dec 2018 14:19:39 CET -->
<iq xmlns="jabber:client" type="set" from="user1@localhost" to="deregister@conference.localhost" id="unreg2">
<query xmlns="jabber:iq:register">
<remove />
</query>
</iq>
<!-- Incoming Tue 18 Dec 2018 14:19:39 CET -->
<presence xmlns="jabber:client" from="deregister@conference.localhost/user1" to="user1@localhost/gajim.LC22DSJ7" id="ca8e9f41-399e-44d3-932c-4cef78818e32">
<x xmlns="vcard-temp:x:update">
<photo />
</x>
<c xmlns="http://jabber.org/protocol/caps" ver="EhDgXYarwDkGz8n/wbp2z37FJWE=" hash="sha-1" node="http://gajim.org" />
<x xmlns="http://jabber.org/protocol/muc#user">
<item affiliation="none" role="participant" jid="user1@localhost/gajim.LC22DSJ7" />
<status code="110" />
</x>
</presence>
<!-- Outgoing Tue 18 Dec 2018 14:19:49 CET -->
<message xmlns="jabber:client" type="groupchat" from="user1@localhost/gajim.LC22DSJ7" to="deregister@conference.localhost" id="b47249a4-212d-4497-a30f-237453f85303">
<composing xmlns="http://jabber.org/protocol/chatstates" />
<no-store xmlns="urn:xmpp:hints" />
</message>
<!-- Incoming Tue 18 Dec 2018 14:19:49 CET -->
<message xmlns="jabber:client" type="groupchat" from="deregister@conference.localhost/user1" to="user1@localhost/gajim.LC22DSJ7" id="b47249a4-212d-4497-a30f-237453f85303">
<composing xmlns="http://jabber.org/protocol/chatstates" />
<no-store xmlns="urn:xmpp:hints" />
</message>
<!-- Outgoing Tue 18 Dec 2018 14:19:50 CET -->
<message xmlns="jabber:client" type="groupchat" from="user1@localhost/gajim.LC22DSJ7" to="deregister@conference.localhost" id="f688a457-6e19-4f1b-bf06-f23303c9b1ea">
<body>hi</body>
<origin-id xmlns="urn:xmpp:sid:0" id="f688a457-6e19-4f1b-bf06-f23303c9b1ea" />
<active xmlns="http://jabber.org/protocol/chatstates" />
</message>
<!-- Incoming Tue 18 Dec 2018 14:19:50 CET -->
<message xmlns="jabber:client" type="groupchat" from="deregister@conference.localhost/user1" to="user1@localhost/gajim.LC22DSJ7" id="f688a457-6e19-4f1b-bf06-f23303c9b1ea">
<body>hi</body>
<origin-id xmlns="urn:xmpp:sid:0" id="f688a457-6e19-4f1b-bf06-f23303c9b1ea" />
<active xmlns="http://jabber.org/protocol/chatstates" />
</message>
MattJ
on
This was fun. The tests I committed sometimes failed, sometimes passed. As in, I simply changed the title of the tests and it made the test pass :)
This narrowed down the possible causes, and led me to the source of the problem. Essentlally two sub-modules within the MUC component were conflicting with each other, when it came to deciding what the default role of an occupant should be when they have no affiliation.
At each Prosody startup, one of the modules would "win". Sometimes the correct one would win, and everything worked fine. Other times the wrong one would win, and this specific behaviour would break. So each Prosody restart had a 50% chance of having or not having the bug.
I fixed the priorities in https://hg.prosody.im/trunk/rev/5281a795d6df so that the logic for members-only rooms will always win, and everything should be fine now.
Thank you for your help in both discovering the issue and for all the testing and information you provided to help get to the bottom of the problem!
What steps will reproduce the problem? 1. Juliet joins a new MUC 2. Juliet configures it members-only 3. Juliet invites Romeo 4. They both chat 5. Romeo de-registers himself from the room What is the expected output? 6. Romeo loses its affiliation and is kicked from the room What do you see instead? 6. Romeo loses its affiliation but stays in the room 7. Romeo can still send a message What version of the product are you using? On what operating system? 0.11.1-1~stretch1/Debian stretch Please provide any additional information below. <!-- ROOM CONFIGURATION QUERY --> <!-- Outgoing Tue 18 Dec 2018 14:23:44 CET --> <iq xmlns="jabber:client" from="user1@localhost" type="get" to="deregister@conference.localhost" id="ik3vs715"> <query xmlns="http://jabber.org/protocol/disco#info" /> </iq> <!-- Incoming Tue 18 Dec 2018 14:23:44 CET --> <iq xmlns="jabber:client" type="result" from="deregister@conference.localhost" to="user1@localhost/gajim.LC22DSJ7" id="ik3vs715"> <query xmlns="http://jabber.org/protocol/disco#info" node=""> <feature var="http://jabber.org/protocol/muc#request" /> <feature var="muc_unsecured" /> <feature var="muc_temporary" /> <feature var="muc_membersonly" /> <feature var="muc_hidden" /> <feature var="http://jabber.org/protocol/muc" /> <feature var="http://jabber.org/protocol/muc#stable_id" /> <feature var="muc_unmoderated" /> <identity type="text" name="deregister tests" category="conference" /> <feature var="muc_semianonymous" /> <feature var="jabber:iq:register" /> <x type="result" xmlns="jabber:x:data"> <field type="hidden" var="FORM_TYPE"> <value>http://jabber.org/protocol/muc#roominfo</value> </field> <field type="text-single" var="muc#roominfo_lang"> <value /> </field> <field type="boolean" label="Allow members to invite new members" var="{http://prosody.im/protocol/muc}roomconfig_allowmemberinvites"> <value>0</value> </field> <field type="text-single" label="Title" var="muc#roomconfig_roomname"> <value>deregister tests</value> </field> <field type="text-single" label="Description" var="muc#roominfo_description"> <value /> </field> <field type="boolean" var="muc#roominfo_changesubject" /> <field type="text-single" label="Number of occupants" var="muc#roominfo_occupants"> <value>2</value> </field> </x> </query> </iq> <!-- DE-REGISTERING QUERY AND MESSAGING --> <!-- Outgoing Tue 18 Dec 2018 14:19:39 CET --> <iq xmlns="jabber:client" type="set" from="user1@localhost" to="deregister@conference.localhost" id="unreg2"> <query xmlns="jabber:iq:register"> <remove /> </query> </iq> <!-- Incoming Tue 18 Dec 2018 14:19:39 CET --> <presence xmlns="jabber:client" from="deregister@conference.localhost/user1" to="user1@localhost/gajim.LC22DSJ7" id="ca8e9f41-399e-44d3-932c-4cef78818e32"> <x xmlns="vcard-temp:x:update"> <photo /> </x> <c xmlns="http://jabber.org/protocol/caps" ver="EhDgXYarwDkGz8n/wbp2z37FJWE=" hash="sha-1" node="http://gajim.org" /> <x xmlns="http://jabber.org/protocol/muc#user"> <item affiliation="none" role="participant" jid="user1@localhost/gajim.LC22DSJ7" /> <status code="110" /> </x> </presence> <!-- Outgoing Tue 18 Dec 2018 14:19:49 CET --> <message xmlns="jabber:client" type="groupchat" from="user1@localhost/gajim.LC22DSJ7" to="deregister@conference.localhost" id="b47249a4-212d-4497-a30f-237453f85303"> <composing xmlns="http://jabber.org/protocol/chatstates" /> <no-store xmlns="urn:xmpp:hints" /> </message> <!-- Incoming Tue 18 Dec 2018 14:19:49 CET --> <message xmlns="jabber:client" type="groupchat" from="deregister@conference.localhost/user1" to="user1@localhost/gajim.LC22DSJ7" id="b47249a4-212d-4497-a30f-237453f85303"> <composing xmlns="http://jabber.org/protocol/chatstates" /> <no-store xmlns="urn:xmpp:hints" /> </message> <!-- Outgoing Tue 18 Dec 2018 14:19:50 CET --> <message xmlns="jabber:client" type="groupchat" from="user1@localhost/gajim.LC22DSJ7" to="deregister@conference.localhost" id="f688a457-6e19-4f1b-bf06-f23303c9b1ea"> <body>hi</body> <origin-id xmlns="urn:xmpp:sid:0" id="f688a457-6e19-4f1b-bf06-f23303c9b1ea" /> <active xmlns="http://jabber.org/protocol/chatstates" /> </message> <!-- Incoming Tue 18 Dec 2018 14:19:50 CET --> <message xmlns="jabber:client" type="groupchat" from="deregister@conference.localhost/user1" to="user1@localhost/gajim.LC22DSJ7" id="f688a457-6e19-4f1b-bf06-f23303c9b1ea"> <body>hi</body> <origin-id xmlns="urn:xmpp:sid:0" id="f688a457-6e19-4f1b-bf06-f23303c9b1ea" /> <active xmlns="http://jabber.org/protocol/chatstates" /> </message>
This was fun. The tests I committed sometimes failed, sometimes passed. As in, I simply changed the title of the tests and it made the test pass :) This narrowed down the possible causes, and led me to the source of the problem. Essentlally two sub-modules within the MUC component were conflicting with each other, when it came to deciding what the default role of an occupant should be when they have no affiliation. At each Prosody startup, one of the modules would "win". Sometimes the correct one would win, and everything worked fine. Other times the wrong one would win, and this specific behaviour would break. So each Prosody restart had a 50% chance of having or not having the bug. I fixed the priorities in https://hg.prosody.im/trunk/rev/5281a795d6df so that the logic for members-only rooms will always win, and everything should be fine now. Thank you for your help in both discovering the issue and for all the testing and information you provided to help get to the bottom of the problem!
Changes