Lua doc & lobby always on / JWT

Developers
#1

Is there some documentation somewhere on what can be done in Lua with prosody/jitsi? Especially around Lobby feature.

We are trying to turn on lobby automatically when the moderator joins the room. We have a setup with Lobby / JWT (with moderator attribute and https://github.com/nvonahsen/jitsi-token-moderation-plugin). We don’t want the moderator to have to turn on lobby manually.

Also there is also another problem with our current setup

  • Moderator joins / create a room (JWT moderator attribute true)
  • Moderator turns on lobby (wish this was automatic)
  • Non Moderator joins (JWT moderator attribute false) / Moderator accepts him
  • Moderator drops
  • Moderator cannot join anymore (get stuck in the lobby, shouldn’t need to wait for someone to accept him)

Essentially is there a way for Moderators (with JWT attribute) to be automatically accepted without getting stuck in Lobby?

Thanks

#2

@Sam_Lellouche,

I would start by reviewing the existing plugins. You could write something that hooks to muc-room-pre-create, muc-occupant-joined, or muc-occupant-pre-join, etc.

This topic may also help: How to get auth_token in muc-room-created and muc-room-destroyed events?

Regarding:

Look in the etc/prosody/conf.d/meet.example.com.cfg.lua file for muc_lobby_whitelist. This can be used to bypass the lobby. If you don’t see that in you cfg, add it under lobby_muc

#3

should be easy

--- mod_muc_lobby_rooms.lua.sav	2020-07-23 21:50:37.000000000 +0200
+++ mod_muc_lobby_rooms.lua	2020-08-03 16:38:45.421840379 +0200
@@ -372,6 +372,13 @@
             end
         end
     end);
+
+    host_module:hook('muc-set-affiliation', function(event)
+        if jid_split(event.jid) ~= 'focus' and event.affiliation == 'owner' then
+	    handle_create_lobby(event);
+        end
+    end);
+
 end);
 
 -- Extract 'room' param from URL when session is created

if you want to add this to standard Jitsi, all there is to add is a parameter. I guess it’s planned already since this routine that is not called anywhere in the source, it’s purpose should be for something like that.

I don’t think there is anything specific about JWT here; it can happens also with internal authentication (and probably with public access setup but I did not try it).
The fact that a moderator having disconnected by mistake after having enabled the lobby can’t enter again because there is no one to approve the join is a misfeature IMO.
Maybe it could be done by saving somewhere (no idea where in fact :-)) the original owner (see above) and testing if it’s the jid currently disconnecting (no idea how :-)) and then just call room:set_members_only(false); - at this point anyone including the original moderator should be able to join.

1 Like
#4

Thanks for the pointers!
We were able to address both issues with custom Lua plugin (auto-lobby on when moderator joins) and bypass lobby for authenticated moderators so they dont get stuck in limbo.