Instead of polling Prosody for conferences, you could use the event_sync module to notify your backend when rooms are created/destroyed/joined/left. That way, you have all the info your backend to implement a complete joining workflow:
Users authenticate with your own app using whatever mechanism you want, and you decide what room they can join and what rights they have.
You can then generate them the appropriate JWT token and redirect them to the jitsi room
if room not yet created, it means admin not yet joined. You can implement your own “waiting for host” page for this use case
you could even notify the admin via email/slack/whatever that someone is waiting to join
the moment room-created event comes in (i.e. when admin joins room) you can admit them directly without waiting for some poll interval
When sharing links for guest access, you don’t even have to include actual Jitsi room name. You app can handle mapping between between arbitrary ids/names and actual room names (which could be random UUIDs).
Bonus feature: your backend has info about who is currently in room, and list of guests waiting, so you could potentially show admins that info before they join
If you couple this with the reservations plugin you can further lock down your Jitsi deployment by insisting that prosody validates with your backend before a room is created. Otherwise, once a guest has a JWT token that is still within the valid timeframe, they could bypass your app and go directly to your Jitsi server. Reservations also opens up the door for other features like time limits on rooms and max occupancy limits.
Exactly. At the moment we have an application up and running which translates LDAP(S) and Radius authentications into Jitsi Compatible JWT tokens. The great thing about this system is the flexibility. In our case it’s Python based so the authentication is only really limited to the capabilities of Python and its various connector libraries.
Also a great point, better to be event based than polling.
Also a great idea. The information could be used to create a simple admin web-UI for Jitsi. I have not explored much of it yet, but I reckon this is akin to what the Jitsi-admin project is doing.
I had this specific concern when writing my last reply so I’m happy to hear that this can be resolved as well.
All in all an awesome reply, thanks for all the ideas, will look into it!
Hi, I have the exact same setup running, which worked for a long time. The last update broke my setup. Now am am also getting “token_verification error Token nil not allowed to join” for anonymous guests joining.
==> /var/log/prosody/prosody.log <==
Aug 08 09:13:53 boshcc367f28-6cb2-481f-88b9-034f63499bd7 info BOSH client disconnected: session close
Aug 08 09:14:04 mod_bosh info New BOSH session, assigned it sid ‘ec63ce20-c05d-4e7a-9fd6-828280725597’
Aug 08 09:14:04 boshec63ce20-c05d-4e7a-9fd6-828280725597 info Authenticated as firstname.lastname@example.org
==> /var/log/prosody/prosody.log <==
Aug 08 07:15:15 bosh22c7d17f-e4a4-4abe-9326-4d4dfe40bb6b info BOSH client disconnected: session close
Aug 08 07:15:17 mod_bosh info New BOSH session, assigned it sid ‘6caf359d-1b48-4469-bc28-4be80398a2a2’
Aug 08 07:15:17 bosh6caf359d-1b48-4469-bc28-4be80398a2a2 info Authenticated as email@example.com
I am having a similar problem. We have Jitsi working in conjunction with Rocket Chat, when you log in from RocketChat to Jitsi, a token is generated and a room is created. If the room is created, then you can follow the link anonymously. But after updating to 2.0.7577, it became impossible to invite a telephone participant through Jigasi.
If you disable token_verification, then everything works as I expect: it is impossible to create a room without a token, you can follow the link to an existing room, you can connect a participant via jigasi.
hello damenco. thanks for sharing the prosody configuration setting.
earlier ( before 7577) this was already set.
out of curiosity though: domain verification seems like a good idea (from a security perspective). can you share what the domain verification is intended for (what domain is validated ?)
thanks damencho, saghul for fixing this. the prosody variable works for me to. one more question though. in case i do want domain validation: how can i arrange this ?
not sure if the following is important: i run with docker. internal domain = meet.jitsi, external domain = <my.public.domain> and an external reverse proxy that handles tls decryption.