Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Un-muting user not idempotent (resulting in unwanted state) #15378

Closed
winterstefan opened this issue Sep 16, 2019 · 4 comments
Closed

Un-muting user not idempotent (resulting in unwanted state) #15378

winterstefan opened this issue Sep 16, 2019 · 4 comments
Milestone

Comments

@winterstefan
Copy link
Contributor

TL;DR

Muting & then un-muting one user has the side-effect, that he/she will be then able to send messages, even if the entire room gets set to read-only.

The root cause is that whilst un-muting the user, the name is removed from room.muted and added to room.unmuted. That's not idempotent.

Description:

The PR #11311 fixed some issues with read-only & muted of a room. Unfortunately, this fix introduced a side-effect, that may not be intended.

Let's assume the following use case

Action Effect read-only muted unmuted
Chat x has participant random-dude (it's newly created) Everybody can send messages false [] []
random-dude sends spam & therefore gets muted Everybody but the random-dude can send messages false ['random-dude'] []
After stopping spamming, random-dude gets re-activated Everybody can send messages false [] ['random-dude'] ❗️
Now, the entire chat needs to be muted for some time -> moderator sets it to read-only Nobody except the random-dude ❗️ can send messages true [] ['random-dude']

In my humble opinion, the marked (❗️) states are quiet odd. That means, once a user gets re-activated, the user is able to send messages even if the entire room gets muted.
Even if the user gets kicked, its username remains in the room.unmuted array.

This is very error-prone, because the moderator doesn't see which users still are able to send messages.

Steps to reproduce:

  • Follow the mentioned use-case from above
  • For example, you may ...
    • Log into the admin UI as administator
    • Create a blank new room with a participant
    • Open the e.g. Chrome developer tools & watch the WebSocket frames being send
    • Use the administrator to follow the use-case

Expected behavior:

Muting and un-muting one user is idempotent. So a blank new user shall have the same muted-state as a 'muted and then unmuted user' (no record in neither muted and unmuted).

Actual behavior:

A 'muted and then unmuted user' still can send messages in a muted room.

Server Setup Information:

  • Version of Rocket.Chat Server: 1.3.2
  • Operating System: Linux
  • Deployment Method: docker
  • Number of Running Instances: 3
  • DB Replicaset Oplog: true
  • NodeJS Version: 8.11.4
  • MongoDB Version: 4.0.12
@winterstefan
Copy link
Contributor Author

Anybody can confirm that or give a hint how to work around this issue?

@github-actions
Copy link
Contributor

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stat: stale Stale issues will be automatically closed if no activity label Jul 24, 2020
@sharpner
Copy link

don't stale it please bot :-) any updates?

@github-actions github-actions bot removed the stat: stale Stale issues will be automatically closed if no activity label Oct 9, 2020
@ggazzo ggazzo added this to the 6.7 milestone Feb 16, 2024
@ggazzo
Copy link
Member

ggazzo commented Mar 15, 2024

closed by #30050

@ggazzo ggazzo closed this as completed Mar 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants