How to create a single persistant room with obscure URL?

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.

I have enabled Secure Domain so creating rooms require password but the problem is when I leave the room it is destroyed.

Is this a problem though? You can just enter the password again when you come back to the room.

You may use meet.jit.si with an unpredictable room name instead of your own server. Then you don’t have to worry about random people.

This doesn’t prevent random people from creating rooms on your server. You need an authentication system.

You may use token authentication with a long expire time and share a tokenized link with your family. There is no password asked in this case but the link may seem a bit ugly.

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 :smiley:

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.

I’m afraid that’s not an option. I’ve got good reasons to self-host.

You may use token authentication with a long expire time and share a tokenized link with your family. There is no password asked in this case but the link may seem a bit ugly.

this looks promising. Is there documentation for all the authentication schemes? Also is it possible to include the token directly in the URL I’ll be sharing with them?

All you need to do is installing the jitsi-meet-tokens package. For more details, check this guide.

apt-get install jitsi-meet-tokens

Or use a third-party installer to install from scratch.

Yes, the end link will be like https://your.domain.com/room-name?jwt=long-token-string. You may create it on jitok

Thanks for the pointers! Super useful.

it’s not possible to have tokens that never expire is it?

If you don’t want the token to expire, just set an expiry that’s far into the future e.g. 10 years.

Thanks! I’ll give that a go. Is it possible to adopt the approach suggested here?

I basically want to have a single room that’s always there and has no passwords.
The only security I want is disabling creating any other rooms.

See if this posted helps:

1 Like

This would work to block creation of other rooms by anybody (including you and your family members). Just have the name of your one room in place of where I had (French|Spanish|TeacherChat)

1 Like

very smart! This is exactly what I was looking for

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.

1 Like

@jbg - I totally agree. Thats not how I would do it securely. Having said that, many people come here looking for quick answers or tips for a proof of concept before diving in deeper.

I actually thought the long expire JWT @emrah and @shawn mentioned was an interesting approach.

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.

1 Like

I agree @jbg @corby. And thanks for all the help so far.

I wanted to add bare minimum protection (without making it difficult for my family to use it) while I figure things out.

The long URL thing is not really an issue as long as it never changes, but I’m still a bit unsure how/if token authentication resolves the persistency issue.

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.