Jibri with jwt

How can I connect jibri with jwt authentication enabled? Don’t want to allow empty tokens.


same here

I managed to hardcode jwt token for jibri and sucessfully made recording with jwt tokens enabled and JWT_ALLOW_EMPTY set to false. JWT token has access to all rooms, but with no moderator rights (we are using mod_token_moderation plugin).
But then there is another problem - since we are using jwt that goes around standard user/password authentication the jibri user that joins conference is visible (not logged to hidden domain). So far, i couldn’t find a way how to hide jibri user.

@damencho is there a way how to authenticate as a different user on different domain from prosody module? My idea is to send in the jwt token special attributes with jibri username and domain to use to authenticate as and use those values in modified mod_auth_token. Something like “rec_user”, “rec_domain” (actual naming irrelevant) and then authenticate as rec_user@rec_domain, but don’t know how to authenticate as a user from prosody module. Can you point me somewhere to start?
Probably authenticate on hiddenDomain would be sufficient for this to work.

1 Like

So after some looking here and there i found out, that the problem was actually somewhere else entirely.

Jibri seems to work completely ok with jwt tokens and jwt_allow_empty set to false, since it is using its own jibri_recorder_user and jibri_recorder_password to login into recorder.xmpp_domain.
The problem was our setup. We are not using welcome page - we disabled it in config.js, but what is more important we made a redirect from root “/” to our own conferencing info page.

And here is the problem: when jibri starts selenium, it first navigates to baseUrl, which is simply root “/” on jitsi domain, here it sets into localStorage in chrome the credentials for jibri user to log in into xmpp for recording and then navigates into actual room and now the actual login happens. But since we redirected from root to another website, the credentials were stored on completely different domain and were not available for jitsi domain in chrome when the actual join to conference room happened.

I modified the first navigation to lead to something more neutral “${baseUrl}/config.js”, which goes around our redirect and voilá, all works well - jibri recordings, with jitsi using jwt with jwt_allow_empty false.

1 Like


Where did you modify the first navigation, on the Jibri server I assume? If so, is it in a config file, or in the source code somewhere that then requires a recompilation?

Any pointers would really be appreciated.



@GKevinGodwin610 here is a part of our jibri patch file, that does that

--- ./jibri/src/main/kotlin/org/jitsi/jibri/selenium/JibriSelenium.kt   2020-01-21 11:59:15.062602476 +0100
+++ ./jibri/src/main/kotlin/org/jitsi/jibri/selenium/JibriSelenium.kt   2020-01-14 00:35:17.411325159 +0100
@@ -244,7 +251,7 @@
         // These are all blocking calls, so offload the work to another thread
         TaskPools.ioPool.submit {
             try {
-                HomePage(chromeDriver).visit(callUrlInfo.baseUrl)
+                HomePage(chromeDriver).visit("${callUrlInfo.baseUrl}/config.js")

                 val localStorageValues = mutableMapOf(
                         "displayname" to jibriSeleniumOptions.displayName,

Obviously, you will have to recompile jibri from source codes to get the binary.

@bbaldino wouldn’t this be a better thing for everyone?

This feels like something pretty specific to your deployment (given that you redirect root)? I don’t remember anyone else reporting this problem.