I just installed jitsi on my server and trying to wrap my head around things so I hope this question is not too basic.
So Here’s my use case: I just want to have a single persistent room that my family can use at all times. I obviously don’t want random people who somehow end up on the URL to be able to create other rooms but I also don’t want my family to deal with entering passwords.
I thought maybe I could have security via using a long weird name for the room so the URL is a bit obscure. Is this reasonable?
I have enabled Secure Domain so creating rooms require password but the problem is when I leave the room it is destroyed. But I think I do need Secure Domain because without it anyone can create a room.
Using an obscure name for your room + using secure domain to prevent rooms being created by unauthorised users is reasonable.
Thanks, good to know!
I want everyone else in the family to be able to use the room when I’m not in the room. But right now if I’m the only one in the room and leave the call the room dies.
Some of the people using this are old and not tech-savvy so I want to make the whole thing as simple as possible for them. There’s no way they’re going to remember the password
I learned I can share a link with them in the org.jitsi.meet://mycustomurl/roomname format and on iOS it directly goes to the app. Unfortunately there doesn’t seem to be a way to have the password in the URL.
Do bear in mind that this doesn’t actually prevent the creation of other rooms on your self-hosted instance, it just makes it a little bit harder (user could use JS console or userscript to change the MUC name that is connected to — nothing requires it to be the same as the path the frontend was loaded at — or they could connect to your self-hosted backend using their own frontend).
This might be fine if you just want to stop casual usage of your instance, but if you want to do it securely you would have to enforce valid MUC names in Prosody. There’s a module, mod_muc_restrict_rooms, but I don’t think it works on Prosody 0.12. Maybe there are other similar modules or this could be updated.
You could always do your own ‘URL shortener’ for the long expiry JWT; make an nginx redirect (must be redirect, not just rewrite) rule from /your-difficult-to-guess-room-name to /your-difficult-to-guess-room-name?jwt=....
That way you can enforce JWT on the domain, preventing any other rooms from being created, but not have to share a URL with a long JWT in it. The control of access to that one room does depend entirely on the unguessable nature of the room name, but if strangers start turning up in your room one day you can always change the name.
Make the JWT with the room parameter set to the same room name so that a leaked token can’t be used to create another room.
In a way, persistence becomes a non-issue if you use token auth and only allow authenticated (someone with valid token) to create/join a room. You’re not relying on any particular room attribute set from previous sessions (e.g. when you rely on lobby or passwords) to stick around to protect the room.