Lobby room enabled by default?

Install & Config
#1

Hello,
we have integrated jitsi meet into our videoconferencing system including the login system for those who want to open a room.

Each account therefore has a personal room code that is always the same (not random).

It would be great if you could choose to have rooms start with lobby enabled by default.

The same goes for the room password.

@damencho do you know if this development is planned?

#2

If you have already a login system maybe JWT is a better option

#3

Thanks for your answer.

How can I take advantage of JWT?

#4

Since you have already a login panel, you can redirect the client to a choosen room with the special permission (moderator or member) using JWT. You can prevent unauthorized clients to access your rooms.

You can specify some features based on tokens. For example, enabled the desktop sharing for some users and disabled for some others…

#5

It must be said that participants do not pass by login …

#6

JWT + guest

#7

Due to the way our system is set up, we cannot use JWT. Do you know other ways?

#8

I didn’t use the lobby much, no idea how to enable it by default

#9

Ok thanks.
Please @damencho help me !

#10

You can write a custom prosody module, which can enable lobby on room creation and do whitelisting on some participants (the moderators) so they are able to join the room without knocking, as there is nobody there to allow them to enter. You can query your system checking who are the whitelisted participants …
Same module can enable set the password by querying your service to obtain it …
There are plenty of examples in the prosody-modules folde.
There are global events for creating and destroying lobby rooms:


1 Like
#11

It might be trivial to you, but can you give an exact example, how to do that?

#12

Nobody said it is trivial, it is not, as you need to consider synchronization as you will create http requests when those can be responded later and you need the information when participant is joining. You may think of some workaround specific for your case.
You can modify existing lobby, here is where whitelist is implemented

I don’t have an example, if I need to give you an example, I need to do your work …

#14

Hi @damencho!

What do you think of the following solution?

setTimeout (() => APP.store.dispatch (toggleLobbyMode (true)), 100);

as the last command of conference.js _onConferenceJoined ()

Thanks !

#15

You need to do that after receiving the event that the participant is moderator

#16

Ok!

Thanks to your tip, we’ve moved the lobby activation to this point in the conference.js class:

room.on(JitsiConferenceEvents.USER_ROLE_CHANGED, (id, role) => {

        if (this.isLocalId(id)) {

            logger.info(`My role changed, new role: ${role}`);

            APP.store.dispatch(localParticipantRoleChanged(role));

            APP.API.notifyUserRoleChanged(id, role);

            if (role == 'moderator') {

                APP.store.dispatch(toggleLobbyMode(true));

            }

        } else {

            APP.store.dispatch(participantRoleChanged(id, role));

        }

    });

I state that in our solution we have set the single moderator.
When the lobby is active there is a problem in which the moderator, by mistake leaving the room, is no longer able to re-enter it.

We solved it by forcibly exiting all participants:

room.on(JitsiConferenceEvents.USER_LEFT, (id, user) => {

        // The logic shared between RN and web.

        commonUserLeftHandling(APP.store, room, user);

        if (user.isHidden()) {

            return;

        }

        logger.log(`USER ${id} LEFT:`, user);

        APP.UI.onSharedVideoStop(id);

        if (user.getRole() == 'moderator') {

            this.leaveRoomAndDisconnect();

        }

    });

What do you think about it?

#17

Probably not the best solution, IMO. It’s easier to just make sure the moderator sets some kind of password once in the meeting, so should they leave the room for any reason, they can rejoin using the password. Forcibly disconnecting everyone else because of the moderator’s mistake (or even system error) is probably not good practice.

#18

Yes, we agree that, in the event of a moderator error, the forced exit is not a nice solution.
As you say we could study a password mechanism to allow the moderator to re-enter.

The crux of the matter, however, is the other point.

If @damencho blesses my edit I can feel satisfied.