This plugin automatically enables the lobby for all rooms.
To use this, you need to have the Lobby feature already configured and working.
Do not use this plugin unless you have enabled some mechanism for moderators to bypass the lobby. Otherwise, all your users will be stuck in the lobby with nobody to admit them.
This plugin allows you to let some users bypass the lobby by setting a flag in their token. This applies to lobbies enabled manually in the UI or automatically with Lobby Autostart.
To use this, you need to have JWT auth already configured and working.
This is awesome! I just realized we don’t have these cool plugins listed in the handbook here: Third-Party Software | Jitsi Meet – Any chance you could make a PR and link to the repo, and maybe provide a list with a sentence or so about each?
This plugin automatically enables the lobby after any user joins with a JWT token that contains "context.user.lobby": true. Users that are already the the room when the lobby is started is not affect.
Once lobby is started, users that are JWT authenticated and does not have "context.user.lobby": true will be excluded from lobby.
This is different from lobby_autostart in that there is no overhead of starting lobby for every room if you only need it for some rooms. The downside being that it is only really practical if all your users are JWT authenticated.
N.B. This can only be used with Jitsi version >=7849 unless you manually apply the PR mentioned above.
If reservations_enable_lobby_support is enabled in prosody config, lobby will be automatically enabled if the reservation endpoint includes "lobby": true in the success payload.
If reservations_enable_password_support is enabled in prosody config, the plugin will automatically set the room password if the reservation endpoint includes "password": "THE_PASSWORD" in the success payload. Users will then be required to know that password to be able to join the room, or in the case where lobby is enabled, can use the password to bypass the lobby.
N.B. This can only be used with Jitsi version >=7849 unless you manually apply the PR mentioned above.
By triggering “create-persistent-lobby-room” global event from your plugin
mod_persistent_lobby makes it easier for other plugins to start lobby rooms that can survive the main room being empty (a “standard” lobby would get terminated when the empty main room gets automatically deleted by prosody).
See the code for any of the plugins above for examples of how to do this.
Hello and thank you for working to formalize the start of the lobby by incorporating it into the 7882 building. I am migrating my code to this new building but I have some problems …
As you indicated, I used the two lua modules:
mod_lobby_autostart.lua and mod_persistent_lobby.lua
The API that is contacted for the reservation by prosody returns me the two fields (I added them as per your indications):
To make the moderator bypass the lobby I use the APP.store.dispatch (joinWithPassword (“password”)); right in the MEMBERS_ONLY_ERROR of conference.js
Then I’ll try to provide a stronger password .
When I start the room from the web, it happens to me that once I manage to start it correctly (in fact I receive an authentication_required and from there I start the room by going to AuthHandler.requireAuth (room, password). I close the room.
I try again to open the usual room but instead of receiving an authentication_required, I receive many MEMBERS_ONLY_ERROR and only after about 15 seconds I see that an authentication_required returns to me in the console (precisely after a [modules / xmpp / moderator.js] <_r. _allocateConferenceFocusError>: Session expired! - removing) and at that point the room starts.
Not sure I fully understand what’s going on in your case, but you probably don’t want to use “mod_lobby_autostart” if you’re already using the new lobby feature in the reservations module. You’ll end up with two modules attempting to start lobby; never tried that but won’t be surprised if things go a bit screwy.
Try removing lobby_autostart, or disable reservations_enable_lobby_support, and try again?
Ok thank you so much.
It was just an anomaly generated by the double activation of the lobby.
The solution via payload API requires the use of the password present in the payload, correct? On the other hand, does the solution with the lobby_autostart module send the client to enter the password?
Lobby and password support are related but distinct features; you can use either one without the other.
Password serves two purposes. If room has lobby enabled, then you would use password to bypass lobby. If lobby disabled, then nobody can enter the room unless they know the password.
Lobby is typically enabled manually by a moderator after they join the room, so there would already be someone in the room to admit others waiting in the lobby. This gets trickier when lobby is automatically enabled since nobody is in the room yet, and moderator needs to get in first to be able to admit others. Or if the moderator leaves and attempts to rejoin, but everyone else in the room are non-moderators.
If you’re already using JWT auth, then something like token_lobby_bypass would be a good way to solve this with minimal friction for moderators – as far as they’re concerned, they are just joining the room as usual. If token_lobby_bypass is not an option, then automatically setting room password would be an alternative – you can create a simple plugin to set a static password automatically, or use the reservations feature to set dynamic passwords for each room (but you still need a way to inform the moderator of the password).
To answer your question specifically:
Not necessarily. you can enable lobby with reservations without setting password. See above for details.
It does not. It only enables lobby. Lobbies have an option to enter password to bypass lobby, but of course this won’t work if passwords were never set.
It is down to you add in a mechanism to get the moderator. Then the moderator can decide how to let others in – they can manually admit them, or they can see a room password so guests can let themselves in.
When guests are waiting for a room to start, as soon as the moderator starts it, it sometimes happens that the guest gets in before the moderator does … as if he finds a flaw while creating the room and starting it of the automatic lobby …
Interesting. Do you mean the guest is waiting in the lobby and nobody is in the room, and when moderator joins, guest automatically joins without being admitted?
I did not see that behaviour when I was testing the lobby feature. Are you able to consistently reproduce that behaviour?
Also, how is the moderator joining? using password or token_lobby_bypass?
I can reproduce it despite being random. But I can manage to reproduce it with a probability of once in 3 attempts.
The moderator logs in by using the password. I added a call to joinWithPassword (pswd); in conference.js in case JitsiConferenceEvents.USER_ROLE_CHANGED when role is moderator …
… same thing in MEMBERS_ONLY exception
I’m not sure I understand. You have a custom UI code that has password hardcoded, and you automate the joinWithPassword when a moderator joins? Maybe I misunderstood, but this really does not sound like an ideal thing to do.
Is the guest user that’s “escaping lobby” using the same custom UI?
We use the solution based on the reservation, the fastest way seemed to us to use only the reservations_enable_lobby_support command to true in addition to putting in the payload lobby to true and a password …
Doing the startup test of the room, however, this part without active lobby but with password set and users are asked to enter the password … (the prejoin page I expected does not open, where you can ask to knock)
ps. Once the room is started, the manual enabling of the lobby works …
pps. I have clearly disabled the Mod_persistent_lobby and lobby_autostart lua modules as per your suggestions …
You should not disable mod_persistent_lobby. That is required by the reservations module for lobby support as mentioned in docs. You should only disable lobby_autostart.
Do not use this plugin unless you have enabled some mechanism for moderators to bypass the lobby. Otherwise, all your users will be stuck in the lobby with nobody to admit them.
. All credit goes to him really.
.