I'm using ejabberd 20.03 and the MucSub approach.
I tried to set affiliation = 'none' but the user can still send messages to the muc. Details:
ejabberd.yml:
...
modules:
mod_adhoc: {}
mod_admin_extra: {}
mod_announce:
access: announce
mod_avatar: {}
mod_blocking: {}
mod_bosh: {}
mod_caps: {}
mod_carboncopy: {}
mod_client_state: {}
mod_configure: {}
mod_disco: {}
mod_fail2ban:
c2s_auth_ban_lifetime: 10
mod_http_api: {}
mod_http_upload:
put_url: https://@HOST@:5443/upload
mod_last: {}
mod_mam:
## Mnesia is limited to 2GB, better to use an SQL backend
## For small servers SQLite is a good fit and is very easy
## to configure. Uncomment this when you have SQL configured:
db_type: sql
assume_mam_usage: true
default: always
mod_mqtt: {}
mod_muc:
access:
- allow
access_admin:
- allow: admin
access_create: muc_create
access_persistent: muc_create
access_mam:
- allow
default_room_options:
allow_query_users: false
allow_subscription: true # enable MucSub
mam: true
persistent: true
public: false
public_list: false
mod_muc_admin: {}
mod_offline:
access_max_user_messages: max_user_offline_messages
mod_privacy: {}
mod_private: {}
mod_proxy65:
access: local
max_connections: 5
mod_pubsub:
access_createnode: pubsub_createnode
plugins:
- flat
- pep
force_node_config:
## Avoid buggy clients to make their bookmarks public
storage:bookmarks:
access_model: whitelist
mod_push: {}
mod_push_keepalive: {}
mod_register:
## Only accept registration requests from the "trusted"
## network (see access_rules section above).
## Think twice before enabling registration from any
## address. See the Jabber SPAM Manifesto for details:
## https://github.com/ge0rg/jabber-spam-fighting-manifesto
ip_access: trusted_network
mod_roster:
versioning: true
mod_s2s_dialback: {}
mod_shared_roster: {}
mod_stream_mgmt:
resend_on_timeout: if_offline
mod_vcard: {}
mod_vcard_xupdate: {}
mod_version:
show_os: false
Room Settings:
[{title,<<"500">>},
{description,<<"500">>},
{allow_change_subj,false},
{allow_query_users,false},
{allow_private_messages,false},
{allow_private_messages_from_visitors,anyone},
{allow_visitor_status,true},
{allow_visitor_nickchange,true},
{public,false},
{public_list,false},
{persistent,true},
{moderated,true},
{members_by_default,true},
{members_only,true},
{allow_user_invites,false},
{password_protected,true},
{captcha_protected,false},
{password,<<"_500_">>},
{anonymous,false},
{logging,false},
{max_users,200},
{allow_voice_requests,true},
{allow_subscription,true},
{mam,true},
{presence_broadcast,[moderator,participant,visitor]},
{voice_request_min_interval,1800},
{vcard,<<"
<vCard
xmlns='vcard-temp'>
<TITLE>Room Title</TITLE>
<DESC>Room Description</DESC>
</vCard>">>},
{vcard_xupdate,<<>>},
{pubsub,<<>>},
{lang,<<"en">>},
{captcha_whitelist,[]},
{affiliations,[{{<<"21112">>,<<"domain.com">>,<<>>},
{admin,<<>>}},
{{<<"21247">>,<<"domain.com">>,<<>>},
{member,<<>>}},
{{<<"21966">>,<<"domain.com">>,<<>>},
{member,<<>>}},
{{<<"admin">>,<<"domain.com">>,<<>>},
{owner,<<>>}}]},
{subject,[]},
{subject_author,<<>>}]
I want user 21112 (room admin) to be able to set user 21247 (room member) in a state that prevents 21247 from sending messages to the room, but 21247 can still receive messages from the room. I tried:
- Logged in with user 21112 and sent the following stanza:
<iq from="[email protected]/14965894906297405984175442" id="revoke_voice_c4ec85d0-7f14-11ea-8f19-77e4dd9aaad8" to="[email protected]" type="set"
xmlns="jabber:client">
<query
xmlns="http://jabber.org/protocol/muc#admin">
<item nick="21247" role="visitor"/>
</query>
</iq>
and received an error:
<iq
xmlns='jabber:client' xml:lang='en'
to='[email protected]/14965894906297405984175442'
from='[email protected]'
type='error'
id='revoke_voice_c4ec85d0-7f14-11ea-8f19-77e4dd9aaad8'>
<query
xmlns='http://jabber.org/protocol/muc#admin'>
<item nick='21247' role='visitor'/>
</query>
<error code='405' type='cancel'>
<not-allowed
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xml:lang='en'
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Changing role/affiliation is not allowed
</text>
</error>
</iq>
I don't know why the error above is being returned. I've read the room configs and also the MucSub approach and I'm wondering if this is because of the MucSub implementation. I don't know. Then I just set the user 21247 affiliation to 'none', but still he is being able to send message to the room. The stanzas:
<iq from="[email protected]/14965894906297405984175442"
id="change_affiliation"
to="[email protected]"
type="set"
xmlns="jabber:client">
<query
xmlns="http://jabber.org/protocol/muc#admin">
<item affiliation="none" jid="[email protected]" nick="21247"/>
</query>
</iq>
<iq
xmlns='jabber:client'
xml:lang='en'
to='[email protected]/14965894906297405984175442'
from='[email protected]'
type='result'
id='change_affiliation'/>
In my understanding, since I set affiliation = 'none', I expected user 21247 not be able to send messages to the room, but can still receive new messages because he is a subscriber of the room (MucSub). Does anyone have ideas to achieve my goal?
