Hi Jitsi family,
I noticed an issue on the self-hosted Jitsi. If the lobby is active, when I leave room as moderator (during internet connection loss or another technical problem), cannot join again. I am stuck in the lobby, and it was said that “Asking to join meeting”.
Is there any way to solve this? Maybe moderator authorization can be transferred to another person as temporary who can let me in again. Or lobby room can be deactivated if there is stored moderator cookie and session data on the browser from the previous session. I’m open to your suggestions.
there is an easy solution, set a password on the meeting. It will bypass the lobby.
thank you @gpatel-fr, but I don’t want to force participants to enter passwords. The password is a workload and a challenge you and your participants always have to reach. When someone comes to the meeting, they can enter the room under moderator control without entering a password. That’s why we are using the lobby.
Password allows to bypass the lobby, but if you don’t know the password you have to use the lobby. So nothing will change for your users.
please correct me if I’m wrong. I created a meeting, activated the lobby and was set up a password. And participants have come. Everyone needs to enter the meeting password to join the meeting. Did you mean there is another password that the participants will not affect it?
No. Just no. Did you even try it ?
Yes tried. When I set the meeting pass, everyone need to enter password to join meeting. Even lobby is activated.
That shouldn’t happen though. If lobby is enabled, guests don’t need to use a password - they just request access.
Or maybe because you see the password field on the join page, you’re assuming it’s required? You can ignore it and just request access.
On meet.jit.si, this is what I see after I attempt to join a room that has a password and lobby enabled:
I was not asked for a password, but I can enter one to join without waiting for someone to let me in.
I think that meet.jit.si is different from many deployments in that it has Jigasi enabled; from AbstractLobby.js:
if this undocumented flag is set, the password field is not displayed at first.
This is not to say that it would be a good idea to set this flag just to not display the password when Jigasi is not installed. It would be a terrible idea. I tested it for you, don’t do it.
This said, meet.jit.si still works like it has always worked and all well behaved Jitsi-meet setups do: if a lobby is enabled and a password is set, asking for entry in the lobby works without password when granted by the moderator.
The difference here is whether pre-join is enabled or not. The screens are different, there is a pre-join screen supporting lobby and just a lobby screen. Maybe this is the difference …
You are right, as always. If I enable prejoin on my test instance, the password field disappears from the initial lobby screen. Or are you ? If I disable prejoin screen from meet.jit.si, the password field does not appear.
Looking at the code, it can be qualified of ‘generous’ in tests and code paths.
Thank you for your great suggestions and answers.
Is it possible to autoconfigure and set the default password for the meeting? I would like to default password to be automatically set when the host starts the meeting.
Setting a password automatically with meet.jit.si is not possible AFAIK. If you have your own instance, the feature is not available out of the box, but it’s at least theoretically possible with a bit of development - using the iFrame Api it is possible to create a meeting and set a password (and many other things too).
thank you @gpatel-fr I have my own instance. Are there any other options to do this except iFrame API? (with prosody etc.)
I think that It’s possible to have persistent rooms with password, yes. I remember having seen posts on this forum describing it - it was quite some time ago.
I have never looked into it, so I’d advise you to search the forum as I can’t help here, AFAIK there is no Prosody module that you just would have to install.
In my opinion the iFrame Api is a better way because it’s easier for users to set (and change if needed) their own password without having to ask an administrator but it’s your call obviously.