Bug in Breakout Rooms, Sorry! You are not allowed to be here

Also happens on meet.jit.si!
Steps to reproduce:
Create a breakout room
Join the breakout room
Join the main room with “Join” on the main room
Reload page

If it still works, do it again

I think the new update doesnt like me.
Now I am getting for a specific room I also used in the past “Sorry! You’re not allowed to be here!” and I cannot figure out why. I am not using any kind of auth, everything on anonymous. What could cause that?

Screenshot 2021-12-10 230920

It happens when you create a breakout room, then join back to the main room and then reload the page.

I’ve seen this reported for specific room names. Do you get the same error on meet.jit.si? Do you get the same error if you use another room name?

I just used aasdasd as room name or something, nothing special

I can’t reproduce this on meet.jit.si or on my own deployment. I tried the room name, created a breakout room, joined it, left it and went back to the main room, reloaded the page, no error message. Reload takes me back to the pre-join screen as expected. Did this several times, same result - no error.

I will try to catch that

What browser (and version) are you testing with?

Google Chrome 96.0.4664.93 (Offizieller Build) (64-Bit) (cohort: Stable)
Überarbeitung 17531e0a70b4f8108f2418e8b5117f465077710b-refs/branch-heads/4664@{#1229}
Betriebssystem Windows 10 Version 21H1 (Build 19043.1387)
JavaScript V8

Also happens on edge on my customers device, also on the offical meet.jit.si
Screenshot 2021-12-10 234249

I can do that with every room name I want, here I am switching quickly to trigger that, already happened just by switching to it and then switching back once

Perhaps the quick switching affected the signaling? I tried it several times with just regular back and forth and didn’t see the error. Maybe switching quickly is causing some signal overload of some sort in prosody or jicofo? Is something cached in the browser that’s causing it? Can you gather logs from those components in another test and share?

I just reproduced it by switching really fast several times and then ending the call before trying again. I wonder if there is some kind of blacklist that’s enforced when such quick, repeated actions are detected. :thinking:

Here it is with “normal use” speed :smiley:

I unfortunately lost the access to the customers machine, I would need to set one up but as you can see that is reproducable, so shouldnt be a problem for anyone to reproduce. I dont got the ressources to set one up myself rn

Also happens on Firefox 94.0.2 (64-Bit)

Yeah, but you still went back to the same room, ran the same actions within a short period of time. Of course, I could be wrong and this may actually be an unintended bug, but I can also see how it could have been a decision made to prevent bot action. In my mind, this could be something similar to what happens when you make multiple attempts to login to a site within a short period of time. However, I’m just guessing here…

1 Like

Possible, sure, but then it is configured a bit too sensitive maybe, when I met with my customer we just switched to the breakout room and switched back and then it already happened with the first switch, so… this is really annoying if that is intended

Thanks for the investigation here folks, we’ll take a look!

1 Like

Hey, any news on this?

I saw that on a self hosted token instance yesterday, realized that the

 /etc/prosody/conf.avail/{{ inventory_hostname }}.cfg.lua

was a bit out of date in general, and instead of debugging I just replaced it with a new one. Bug then has disappeared.

I just experienced this and I think it is a bug in jicofo, restarting jicofo fixed it.

Does restarting Jicofo fix the bug or make the error disappear (till it shows up some other time)?

Jicofo restart fixes it

It is per room

1 Like