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

[Audio] disconnect command should check if the user is actually in the VC #6365

Open
cool-aid-man opened this issue Apr 22, 2024 · 6 comments · May be fixed by #6385
Open

[Audio] disconnect command should check if the user is actually in the VC #6365

cool-aid-man opened this issue Apr 22, 2024 · 6 comments · May be fixed by #6385
Labels
Status: Needs Triage This has not been labeled or discussed for handling yet. Type: Bug Unexpected behavior, result, or exception. In case of PRs, it is a fix for the foregoing.

Comments

@cool-aid-man
Copy link

cool-aid-man commented Apr 22, 2024

What Red version are you using?

3.5.9

Cog name

Audio

Command name

disconnect

What did you expect to happen?

  • Just like the summon command - the disconnect cmd should also check if the user (who is invoking the command) actually is in the VC before letting them disconnect the bot from the VC - where it's already playing songs along with other humans.
    image

What actually happened?

It lets anyone who is not in the VC, run the command resulting in the bot getting disconnected from the VC, leading to an unpleasant experience.

How can we reproduce this error?

  1. Connect to a VC
  2. Set the vote percentage to 0 by audioset vote 0
  3. Summon the bot to join
  4. Ask any user or <p>mock anyone to run <p>disconnect
    Result - It should let that user x disconnect the bot without having to be there in the VC.

The summon command ONLY works if you are in the VC - likewise, the disconnect should also work if the user is in the VC, regardless of the status of the audioset vote.

Same result with or without the human. (Meaning if the bot is alone or with other users doesn't matter)

Anything else?

N/A

@cool-aid-man cool-aid-man added the Type: Bug Unexpected behavior, result, or exception. In case of PRs, it is a fix for the foregoing. label Apr 22, 2024
@github-actions github-actions bot added the Status: Needs Triage This has not been labeled or discussed for handling yet. label Apr 22, 2024
@aikaterna
Copy link
Member

Sounds like the person that ran disconnect is a priviledged user like a server owner or a mod or admin set through Red.

@aikaterna
Copy link
Member

Also another thing to note is that the permissions system for audio will not adhere to restrictions if there is no one in the channel or if they are alone.

@cool-aid-man
Copy link
Author

Sounds like the person that ran disconnect is a priviledged user like a server owner or a mod or admin set through Red.

Hi aika, I can confirm that this is not the case here,

  • I joined as server owner + with the bot in a VC - so the bot is not alone.
  • The user neither has the moderator nor admin privilege not even set by the set command - In fact the user doesn't have any perms besides send_message.
  • The bot doesn't have permissions override set by permissions cog, I had cleared all the permissions just to be extra safe.
  • There's no DJ role set through the audioset dj.
  • Audioset vote is set to 0 audioset vote 0 (If the audioset vote is set to any percentage then it would have asked the user - "There are other people listening - vote to skip instead.")

@ProfessorFartsalot
Copy link

ProfessorFartsalot commented May 30, 2024

I also have this issue. I can summon my Red instance to a voice channel, and my alt account (with only the @\everyone role) can disconnect the instance despite the user not being in the voice channel.

Edit: clarification, accidental ping, the sky is now on fire...

@ProfessorFartsalot
Copy link

ProfessorFartsalot commented May 30, 2024

image

image

@BenCos17
Copy link

can confirm that it's the same for me also

@Flame442 Flame442 linked a pull request May 31, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Needs Triage This has not been labeled or discussed for handling yet. Type: Bug Unexpected behavior, result, or exception. In case of PRs, it is a fix for the foregoing.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants