Jitsi Meet, pre-create rooms with password for anonymous users

I volunteered to set up a server for some school classes to support home-schooling. The Installation went fine.
Each class shall have their own room. Each room shall have a pre-configured password. Everyone knowing the room’s URL and password should be able to join anonymously.
There’s not need for any user to create rooms and setting passwords. I imagined I’d just add some rooms and passwords to a config file and revoke permissions for anonymous users.
I’ve expected to find some beginner’s tutorial or a basic documentation on this topic but to no avail. I found numerous hints about settings in some configuration files where I have no idea what they do. Numerous modules were mentioned numerous scripts were posted. I feel that I just didn’t find the right information to solve this and would be happy if someone could point me to the right direction. This question must have been answered multiple times.
I’m on the verge of just adding some http basic auth on the webserver. Then I still have to find a way to prohibit the creation of new rooms.


I found a quite comprehensible (German) tutorial about setting up a password protection for creating new rooms :https://decatec.de/home-server/jitsi-meet-videokonferenz-system-unter-ubuntu-server-mit-nginx/#Oeffentlichen_Zugang_unterbinden_8222Secure_Domain8220
I still have the problem that set up rooms vanish as soon as the last member leaves. With the above change it is now no longer possible to allow users to join without an “organizer” being present.
Is there a way to make rooms “sticky” (with password)?

You may want to check this thread: Persistent Passwords on Self Hosted Rooms

Also, could you provide a link to the german instructions you are referring to? Thanks!

Sorry - forgot to paste the link :blush: fixed
Will have a look, thank you!

Ah, I already came across this thread, but “prosody 0.11 basically broke Jitsi-meet, wherein users who join a conference room cant see each other or chat at all” didn’t sound very promising to me.
“Installed prosody 0.11, set muc_room_default_persistent=true
I set a password, left the call and je-joined. Prosody will crash.”

I presumed that if you just setup the Jitsi Meet instance you are probably using Prosody 0.11 anyways, no?

Maybe - still trying to figure out which module does what. Trying to find out how to read the version of prosody - no hint in man page …

depending on your setup you may be able to user your packetmanager, i.e., dpkg -l prosody

Hi all, trying to accomplish the same here … please if you make this work share the solution.


0.11.2-1 (I expected the package version to diverge from the program’s version)
https://prosody.im/doc/chatrooms looks helpful, too - once I find the location of that config file.
Edit: my fault. Confused some config files.

As I wrote here Persistent Passwords on Self Hosted Rooms , I was not able to do this using persistent rooms. Thats why I used the workaround with the muc-room-created hook, though my usecase was a bit different than yours. Perhaps you can adjust the Lua script to fit your usecase

  1. I added restrict_room_creation = true and muc_room_default_persistent = false
  2. Then I joined a room being prompted to wait for some operator to appear. Selected “I’m operator” entered password and successfully joined the room.
  3. I entered a password for this room
  4. Left the room
  5. re-joined the room
  6. “something went wrong, reconnecting” (in a loop)

Looks pretty mush the same as in Persistent Passwords on Self Hosted Rooms

1 Like

So I assume there’s no place in the config files to manage the chatrooms therein?
I’m pretty confused because I consider my setup pretty standard.

Moving this discussion to Persistent Passwords on Self Hosted Rooms

You can see the version of prosody in /var/log/prosody/prosody.log (a least in Ubuntu). I installed this some days ago with the instructions from github https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md (no docker). In my case the version is 0.10, so the assumption from @plokta is not valid, unfortunately :sob: