Delete All Existing Rooms

I just recently installed my own instance on a local Ubuntu box. Took some trial and error, but I’ve gotten it all working how I like for the moment. One of the things I configured was authentication, so now no new rooms can be created without a password. But during the trial-and-error phase, I’d created some rooms with no authentication and those are still hanging around. They show up in my recent list, and of course if anyone had the URL they could join. How do I close those old unauthenticated rooms? It would be fine if I could easily just remove all rooms, then it’s easy enough to create new ones using the authenticated account. Thanks!

Edit your /usr/share/jitsi-meet/interface_config.js

you can disable the recent list features and restart

then clear your cache

are you sure of that ? it runs counter to the old wisdom that says that Jitsi don’t save rooms when they have no more participants. IMO the room list is saved only locally (probably browser local storage), so no other people can join unless they use your computer.

Plus, the fact there’s a reference to a historic room doesn’t mean - as far as I know - that’s someone could re-create the room without authentication, if you‘ve now got authentication enabled. There’s no persistence to a room, once everyone has left, unless you’ve changed the default config to make that so.

It seems that any random person trying to come in with the room name can’t join that old test room now. (Tested by using a separate browser using VPN.) That worked last night, even when there was no one actively in the room. Now it doesn’t, so presumably something behind the scenes cleaned up the rooms after some kind of timeout. Is there a configuration value for that timeout setting? I’d like to set it to zero so the rooms are immediately cleaned up once everyone leaves.

It does still let me go into the room with no password if I click on the recent list, by the way. Which is not what I’d expect - something must be bypassing authentication when using the recent list, even if the room needs to be created. But that’s not really a problem in this case, only affects me since I was the one testing.

I have a similar issue.
A few days ago Jitsi were installed at a Ubuntu AWS (very easy with the quick install BTW :grinning:)

There is no authentication other that I added the allowed IP’s in .htaccess from enter.php

Currently I have 3 empty rooms persistent at the /index.html list.
One of them is 2 days old and have persisted over EC2 instance reboot.

I’ve tried
systemctl restart prosody.service
without this having any effect.

1 Like

As far as I can tell, Jitsi does not persist any room. The recent list and related information is all in your browser’s local storage. You can clear your browser cache or use a private window to test this. Note however that if you did not setup authentication, any room you join will be created on the fly, no matter whether or not this room existed in the past. As soon as the last participant leaves a room, the room is destroyed (unless there are any bugs or special configurations in your setup).

You are indeed correct.
Before posting I tried pressing Control+F5 and Control+Shift+R to initiate hard reload (Chrome).
Also tried checking Disable cache (while DevTools is open) under DevTools (F12) > Settings.
None of this seems to clear the list at /index.html

However, opening the page in a new Incognito Mode (Chrome) or Private Window (Firefox) shows a clear list.

If I get this correctly, there is some error in web-service not telling the browser to clear the cache. Meaning that the user will get the impression that the rooms are still existing even though Jitsi has destroyed the room as the last participant leaves?

I think each browser implements deletion of localStorage in slightly different ways but you should always be able to view and delete the localStorage from within the devtools (e.g., Application, ClearStorage in Chrome).

Jitsi does not persist any state on the server afaik, so if a user calls a specific room URL the room is either created or the user joins the room, if and only if somebody else already created the room before.

This setting does not seem to affect the mobile app.

All of the rooms that have been created required userid and password for creation but these rooms can be recreated even the next day after everyone has left the room. I followed these instructions for setting up authentication - Authentication for creating meetings

Same problem here. User aren’t forced to authenticate again, if they use “old” rooms the next day or next week’s.
Also more than one user have moderator rights. is there a solution?