Gatekeeping room creation from prosody module

By default, you should already see all the info/error logs in /var/log/prosody/prosody.log.

If you want debug logs as well, you can reconfigure logging in /etc/prosody/prosody.cfg.lua.

You should see see something like this in there:

-- Logging configuration
-- For advanced logging see
log = {
        info = "/var/log/prosody/prosody.log"; -- Change 'info' to 'debug' for verbose logging
        error = "/var/log/prosody/prosody.err";
        -- "*syslog"; -- Uncomment this for logging to syslog
        -- "*console"; -- Log to the console, useful for debugging when running in the foreground

Change info to debug, then restart prosody. You should then start seeing debug entries too.

The logs could get quite noisy after that, but you could grep for “reservations” to just see logs from the reservations module.

@shawn this works for me. Also, on another note, where does the reservation module fetch the room name and the mail id required by the reservation system to make the POST /conference call in your module?

These all come from the event stanza – the room_jid is derived from the the conference room name, and the mail_id is the user jid in the “from” field.

@shawn who makes the call to pre-iq/host global hook?

Prosody makes the call: Events – Prosody IM

In our jitsi setup, pre-iq/host receives a stanza element without any “from” attribute from jitsi meet web app, but when this stanza from the pre-iq/host is intercepted in mod_reservations.lua, there is a “from” attribute present in the stanza with the format @@meet.jitsi

@shawn @damencho Any idea how this happens?

My target is to have this “from” attribute in the stanza to be a constant SSO id. Am I missing something? Any help is appreciated

I’m afraid I don’t know.

But I would expect the “from” attribute to be in the format <id>@<xmppdomain> which I presume in you case the xmpp domain is meet.jitsi.

No idea how, or if it is possible, to replace user jid with a custom ID in another format.

If I had to associated user sessions with some externally managed ID, my initial thought would be to go down the JWT auth route and add the SSO ID as an attribute to the token. I would then lookup the jitsi_meet_context_user for the user session (here’s one way to do it) and include the attached SSO ID in the payload from the reservations service.

No idea if that could work or if it meets your requirements. :man_shrugging:

1 Like

From in incoming xmpp messages is not required and even if it exists, the server will always override it with the jid associated with that authorized account that is used. To avoid spoofing of messages.

You cannot use the from for custom things. Best approach is what @shawn said, about jwt.
There is user id and group id in user context used around in the prosody modules, something we are using for years now.

1 Like

@shawn @damencho JWT is the way to go for a constant SSO id. Without it, prosody uses anonymous authentication resulting in random user ids everytime.