Issue with adding a meeting password

Hello,

I followed your video to setup a Jitsi Meet server including the anonymous guest authentication.  All went smoothly.
However, I noticed the following when create a meeting and adding a shared password.

Scenario 1:
1. The person with host credentials creates a meeting.
2. The host clicks the sharing icon and adds a password.
3. A guest opens jitsi meet app on phone and puts in link.
4.They are prompted for the password the host created.
5. When they do they get into the meeting.

Scenario 2:
1. The person with host credentials creates a meeting.
2. The host clicks the sharing icon and adds a password.
3. The host closes the meeting.
4. A guest opens jitsi meet app on phone and puts in link.
5.They are informed to wait for the host to start the meeting.
6. The host restarts the meeting.
7.The guest immediately enters the meeting, they are not prompted for the password.
8. The guest leaves the meeting and reenters, they are now prompted for the password.

So it seems that this password is not saved with the meeting.

Desired scenario:
1. The person with host credentials creates a meeting.
2. The host clicks the sharing icon and adds a password.
3. The host closes the meeting.
4. The host sends an email to guest participants with the link and password for the meeting that is a week in the future.
5. Before the meeting is started the guests open the jitsi meet app on phone and put in link.
5.They are informed to wait for the host to start the meeting.
6. The host restarts the meeting.
7.The guests are prompted for the password.
8. The guests enter the password and enter the meeting.

So it appears that this password has a giant loophole, those who know about the link can try to enter the meeting and wait for the host to start it and not have to enter the password.

Am I missing something. Is there a way to persist the password?
Thanks, Dennis

 

Also, if you check... when you configure credentials in prosody for the host, al guest members are moderators

dworthem - This is the expected behavior for Jitsi Meet. Rooms are never persistent– when all members leave a room, the room no longer exists (and neither does its password.) A few points I'd recommend considering:

- This "loophole" requires the non-authorized guest to already know the URL of the room and to already be waiting when the host creates the room.

- More importantly, it's not as if a guest can "hide" inside of an active room; the moderator would immediately see that they're in the room, and will have the power to kick them from the room (and if that is done after a password has been set, then the unauthorized guest would not be able to re-join.)

With those items in mind, you have the following ways to keep unauthorized users out of your video conference (in chronological order):

- Don't give out the URL earlier than you need to, and don't give it out to people who don't need it.

- Create the room at least a few minutes in advance so you can set the password before people start showing up.

- When you create the room, if an unauthorized user joins the call immediately, set your password and then kick them. (You could also get their IP address from your NGINX logs and either block them at the firewall level or pursue legal action if this is really a large concern for you.)

I can see how this is an inconvenience in the design of Jitsi Meet, but that's as far as I'd go.

sukubo - I'm not sure what you are referring to. Only the user who authenticates and creates the room is a moderator by default.

Hello Jacob,

Thanks for your response. I think the design could have (apparently) easily added the functionality that I refer to.

When the moderator opens the meeting and the login dialog is shown, in addition to the username and password, the dialog could optionally permit adding a password to the meeting.

I do not know how Zoom works, does it allow a guest to enter a meeting by waiting on the url until the host starts or can it unconditionally force a password entry?

Thanks Dennis

Hi Dennis,

Zoom does not usually use "URLs" since it is not browser-based (from what I understand, having used it only once recently.) Zoom gives you a long, complex, alphanumeric "meeting ID" and also an optional room password. You could also use long, complex, alphanumeric room names for Jitsi that people would not generally guess if you wanted to.

That said, you are not the only person to have this concern; it looks like a few other users have already posted issues on Jitsi's GitHub page about this:

https://github.com/jitsi/jitsi-meet/issues/5720 

https://github.com/jitsi/jitsi-meet/issues/5653 

https://github.com/jitsi/jitsi-meet/issues/5407 

I do agree with your point that this problem could be solved without requiring persistent room storage by allowing a room creator to enter a password at the same time as their credentials. You may want to suggest that to the Jitsi developers in one of the issues linked above.

I followed the install instructions.

But the following is what happens:
1. The person with host credentials creates a meeting.
2. The host clicks the sharing icon and adds a password.
3. A guest opens jitsi meet app on phone and puts in link.
4.*******They are prompted for the password in the credentials window for starting a meeting, not for the password created within the meeting.
****Yes I followed all the way through your video- (awesome by the way)
Gigantic attachment was removed by moderator.

mtb Please open a new thread since this question of yours is not related to Dennis's discussion about the password effectiveness.

Also, you did not follow my tutorial properly if you are seeing this behavior; if you had done that, you would be seeing the behavior that I demonstrated in the video. Please double-check your configuration and remember to restart all of the services after adding the anonymous domain.

jacobgkau said

@dworthem - This is the expected behavior for Jitsi Meet.

Does the OP apply only to Jitsi on your own server or using a browser version of Jisti Meet as well?
 

Nerd Lead said

jacobgkau said

@dworthem - This is the expected behavior for Jitsi Meet.

Does the OP apply only to Jitsi on your own server or using a browser version of Jisti Meet as well?
 

From “Post #440”, April 25th 2020, 12:52 AM

@Nerd Lead What are you talking about? You still access Jitsi Meet through a web browser even if you're hosting it on your own server. Are you talking about a different application?

Hi Nerd Lead
Wonderful article . I have setup a jitsi meet server on aws ec2 instance running on t2.micro 1cpu 1 GB mem 20 Ssd . As of  ow its able to host 5 to 10 participants.  I donated this to a school . Now more schools are asking for this service .
- how can  I enable auto scaling ?
I also referred your other video on Jigri for recording.  Does it mean only one room can record at a time? How to enable permission for multiple rooms to record video?
I am looking for a scalable solution as the  number of school meetings are soon going to be in hundreds and hundreds of live recordings needed … I am planning to hs auto scaling to scale the instances ..but no clue how I can architect the whole solutions.  Pls share your views at dharanibabu@gmail.com for collaborative work in this top need here in India !
Welcome sir
Regards
Sandeep

Sandeep said

How to enable permission for multiple rooms to record video?

From “Post #451”, May 1st 2020, 12:18 PM

The limitation of one room recording at a time is nothing to do with permissions. As I explained in the Jibri video, Jibri starts an X server, runs an instance of Google Chrome using the ChromeDriver, and starts an ffmpeg "screen recording" of the X display. If you want two rooms recording at once, you need two Jibri servers. Three rooms recording at once, three Jibri servers. It's incredibly inefficient.

Sandeep said

how can  I enable auto scaling ?

From “Post #451”, May 1st 2020, 12:18 PM

I don't think there's such a thing as "auto scaling." Definitely nothing "auto" about setting "scaling" up, and I have no clue how you'd go about that.

Hi Jacob
Thanks for your prompt response .
- Given that as per design Jitsi needs 1 Jigri server per room recording I would like like abandon that approach and rather opt for screen capturing from the host's chrome browser using a plugin . What do you think about it ?
- from Jitsi documentation ( which is very limited ..) its suggested we keep Jicofo prosody in a front end server and keep a pool of JVB instances in the backend - in a subnet . Have you experimented or will be able to guide this solution ? I am planning to add JVB instances in an auto scaling group in my aws VPC.  Any thoughts on this please?
Is there any benchmark available like how many hosts × participants can join how many rooms in a 4 CPU + 8 GB RAM vm instance ?
Thanks in advance
Sandeep