Jitsi-meet-tokens chronicles on Debian Buster

emrah · September 1, 2020, 12:25pm

I tried to add jitsi-meet-tokens to my Jitsi server that is already configured but I got some errors. After some research, I realized that this was not an easy task and therefore a new chronicle started.

My server is Debian Buster and the followings are only tested on Debian Buster.

stage 0
When I tried to install the jitsi-meet-tokens I got some error messages

apt-get install jitsi-meet-tokens

>>> luajwtjitsi 1.3-7 depends on luacrypto >= 0.3.2-1 (not installed)
>>> Installing https://luarocks.org/luacrypto-0.3.2-2.src.rock
>>> gcc -O2 -fPIC -I/usr/include/lua5.2 -c src/lcrypto.c -o src/lcrypto.o -I/usr/include
>>> src/lcrypto.c:30:10: fatal error: lua.h: No such file or directory
>>>  #include "lua.h"
>>>           ^~~~~~~
>>> compilation terminated.
>>>
>>> Error: Failed installing dependency: https://luarocks.org/luacrypto-0.3.2-2.src.rock - Build error: Failed compiling object src/lcrypto.o
>>> Failed to install luajwtjitsi - try installing it manually

Another symptom of a broken jitsi-meet-tokens installation is the missing authentication = "token" line in your prosody configuration. Check it with the following command:

egrep '^\s*authentication' /etc/prosody/conf.avail/*.*.cfg.lua

>>> /etc/prosody/conf.avail/mydomain.com.cfg.lua:        authentication = "anonymous"
>>> /etc/prosody/conf.avail/mydomain.com.cfg.lua:    authentication = "internal_plain"

stage 1
The compiler could not find the lua headers for the current version. So I installed it and tried it again

apt-get purge jitsi-meet-tokens
apt-get autoremove --purge
apt-get install liblua5.2-dev
apt-get install jitsi-meet-tokens

>>> gcc -O2 -fPIC -I/usr/include/lua5.2 -c src/lcrypto.c -o src/lcrypto.o -I/usr/include                                                    
>>> src/lcrypto.c: In function ‘digest_pnew’:                                                                                              
>>> src/lcrypto.c:81:61: error: invalid application of ‘sizeof’ to incomplete type ‘EVP_MD_CTX’ {aka ‘struct evp_md_ctx_st’}               
>>>      EVP_MD_CTX *c = (EVP_MD_CTX *)lua_newuserdata(L, sizeof(EVP_MD_CTX));
>>>                                                              ^~~~~~~~~~                    
>>> src/lcrypto.c: In function ‘digest_reset’:                                                                                             
>>> src/lcrypto.c:120:10: warning: implicit declaration of function ‘EVP_MD_CTX_cleanup’; did you mean ‘EVP_MD_CTX_create’? [-Wimplicit-func
tion-declaration]

luacrypto could not be compiled during the installation.

stage 2
After some research I realized that the issue was related in the libssl-dev packages.

The jitsi-meet-tokens package depends to the libssl-dev package to compile luacrypto but libssl-dev depends openssl1.1 on Debian Buster and luacrypto needs the openssl1.0 libraries.

There are two problem here:

There is no installation candidate for libssl1.0-dev on Debian Buster
The jitsi-meet-tokens package don’t accept libssl1.0-dev as an alternative and forces to install libssl-dev which depends on a wrong version of openssl

stage 3
I added the old stable repo to obtain libssl1.0-dev to solve the first issue and sent a pull request to the Jitsi team for the second issue.

apt-get purge jitsi-meet-tokens
apt-get autoremove --purge

echo 'deb http://security.debian.org/debian-security/ stretch/updates main' >> /etc/apt/sources.list.d/stretch.list

apt-get update
apt-get install libssl1.0-dev

Since the jitsi-meet-tokens package was not ready yet, I tested the first issue using luarocks

apt-get install luarocks
luarocks install luacrypto
luarocks list

>>> Installed rocks:
>>> ----------------
>>>
>>> luacrypto
>>>    0.3.2-2 (installed) - /usr/local/lib/luarocks/rocks

luacrypto was installed successfully.

note: luacrypto2 supports openssl1.1 and this could be an alternative way.

stage 4
jitsi-meet-tokens needs lua-cjson and lbase64 too. Therefore I tested to install these two using luarocks.

luarocks install lbase64

>>> Installing https://luarocks.org/lbase64-20120807-3.src.rock
>>> gcc -O2 -fPIC -I/usr/include/lua5.2 -c lbase64.c -o lbase64.o
>>> gcc -shared -o base64.so -L/usr/local/lib lbase64.o
>>> lbase64 20120807-3 is now installed in /usr/local (license: Public domain)

luarocks install lua-cjson

>>> Installing https://luarocks.org/lua-cjson-2.1.0.6-1.src.rock
>>> gcc -O2 -fPIC -I/usr/include/lua5.2 -c lua_cjson.c -o lua_cjson.o
>>> lua_cjson.c: In function ‘json_append_data’:
>>> lua_cjson.c:743:19: warning: implicit declaration of function ‘lua_objlen’; did you mean ‘lua_len’? [-Wimplicit-function-declaration]
>>>              len = lua_objlen(l, -1);
>>>                    ^~~~~~~~~~
>>>                    lua_len
>>> gcc -O2 -fPIC -I/usr/include/lua5.2 -c strbuf.c -o strbuf.o
>>> gcc -O2 -fPIC -I/usr/include/lua5.2 -c fpconv.c -o fpconv.o
>>> gcc -shared -o cjson.so -L/usr/local/lib lua_cjson.o strbuf.o fpconv.o
>>> lua-cjson 2.1.0.6-1 is now installed in /usr/local (license: MIT)

lbase64 was installed successfully. lua-cjson was installed too but there is a warning which may be annoying in the future.

stage 5
I decided to download the lua-cjson source and repack it after fixing the warning.

luarocks remove lua-cjson

cd
mkdir src
cd src

luarocks download lua-cjson
luarocks unpack lua-cjson-2.1.0.6-1.src.rock
cd lua-cjson-2.1.0.6-1/lua-cjson
vim lua_cjson.c

I commented the lines 743 and 744 and added a new line after these

if (as_array) {
    // len = lua_objlen(l, -1);
    // json_append_array(l, cfg, current_depth, json, len);
    json_append_array(l, cfg, current_depth, json, 0);
} else {

note: I learned how to change these lines checking lua-cjson2 source code.

Then I repacked and installed.

luarocks make --pack-binary-rock
luarocks install lua-cjson-2.1devel-1.linux-x86_64.rock

>>> lua-cjson 2.1devel-1 is now installed in /usr/local (license: MIT)

All needed Lua rocks were installed

luarocks list

>>> Installed rocks:
>>> ----------------
>>>
>>> lbase64
>>>    20120807-3 (installed) - /usr/local/lib/luarocks/rocks
>>>
>>> lua-cjson
>>>    2.1devel-1 (installed) - /usr/local/lib/luarocks/rocks
>>>
>>> luacrypto
>>>    0.3.2-2 (installed) - /usr/local/lib/luarocks/rocks

stage 6
Time to rebuild the jitsi-meet-tokens package. I cloned the jitsi-meet repo.

apt-get install git
apt-get install build-essential fakeroot debhelper
apt-get install nodejs

cd ~/src
git clone --depth=1 https://github.com/jitsi/jitsi-meet.git
cd jitsi-meet
vim debian/control

I wanted to rebuild only the jitsi-meet-tokens package, therefore I changed debian/control as the followings

removed all packages except jitsi-meet-tokens
libssl-dev changed to libssl1.0-dev | libssl-dev on Depends

Source: jitsi-meet-web
Section: net
Priority: extra
Maintainer: Jitsi Team <dev@jitsi.org>
Uploaders: Emil Ivov <emcho@jitsi.org>, Damian Minkov <damencho@jitsi.org>
Build-Depends: debhelper (>= 8.0.0), nodejs
Standards-Version: 3.9.6
Homepage: https://jitsi.org/meet

Package: jitsi-meet-tokens
Architecture: all
Depends: ${misc:Depends}, prosody-trunk (>= 1nightly747) | prosody-0.11 | prosody (>= 0.11.2), libssl1.0-dev | libssl-dev, luarocks, jitsi-meet-prosody
Description: Prosody token authentication plugin for Jitsi Meet

And rebuild the package

dpkg-buildpackage -rfakeroot -uc -b

The package is ready to install now

cd ~/src
dpkg -i jitsi-meet-tokens_1.0.1-1_all.deb

>>> (Reading database ... 28654 files and directories currently installed.)
>>> Preparing to unpack jitsi-meet-tokens_1.0.1-1_all.deb ...
>>> Unpacking jitsi-meet-tokens (1.0.1-1) over (1.0.1-1) ...
>>> Setting up jitsi-meet-tokens (1.0.1-1) ...

stage 7
Click here to download the customized jitsi-meet-tokens deb package and click here to download the customized lua-cjson rock.

emrah · September 2, 2020, 9:33am

How I’m installing jitsi-meet-tokens now

echo 'deb http://security.debian.org/debian-security/ stretch/updates main' >> /etc/apt/sources.list.d/stretch.list

apt-get update
apt-get install libssl1.0-dev
apt-get install luarocks liblua5.2-dev

wget https://emrah.com/files/lua-cjson-2.1devel-1.linux-x86_64.rock
luarocks install lua-cjson-2.1devel-1.linux-x86_64.rock

apt-get install jitsi-meet-tokens

edited at 2020-09-24
No need the customized deb package since the stable repo has a fixed one. I changed the post according to the new situation.

emrah · September 4, 2020, 10:56am

JWT with PHP

Tested on Debian Buster

packages

apt-get install php-cli composer
composer require firebase/php-jwt

Simple code

jwt.php

<?php
require_once 'vendor/autoload.php';
use \Firebase\JWT\JWT;

$LINK = "https://meet.mydomain.com";
$ROOM = "myroom";

$key = "mysecret";
$payload = array(
    "aud" => "myapp",
    "iss" => "myapp",
    "sub" => "meet.mydomain.com",
    "exp" => time() + (60*60),
    "room" => "$ROOM",
    "moderator" => true,
    "context" => array(
        "user" => array(
            "name" => "username",
            "email" => "username@mydomain.com",
            "avatar" => "https://gravatar.com/avatar/abc123.png"
        )
    )
);

$jwt = JWT::encode($payload, $key);
echo $LINK . '/' . $ROOM . '?jwt=' . $jwt;
echo "\n";
?>

running

php jwt.php

emrah · October 13, 2020, 6:09am

The installation steps for Ubuntu 20.04

sudo su -l

apt-get update
apt-get install gnupg

echo "deb http://security.ubuntu.com/ubuntu bionic-security main" > /etc/apt/sources.list.d/bionic.list

apt-get update
apt-get install libssl1.0-dev
apt-get install luarocks liblua5.2-dev

wget https://emrah.com/files/lua-cjson-2.1devel-1.linux-x86_64.rock
luarocks install lua-cjson-2.1devel-1.linux-x86_64.rock

apt-get install jitsi-meet-tokens

haris · October 13, 2020, 12:12pm

Hi @emrah,

this is just super helpful. Thank you so much for you brilliant summary!

Works like a charm on Debian 10 (Buster).

Cheers

Harald

subodhs · November 5, 2020, 11:35am

Hi Emrah,

Do you have any steps for JWT Token on Ubuntu 18.04?

Regards,
Subodh

emrah · November 5, 2020, 1:57pm

No, I didn’t do any test on Ubuntu 18.04

jpkelly · November 17, 2020, 3:41am

This worked for me before on Ubuntu 18.04. May be a bit outdated.

Enable JWT

Install lua components

cd &&
apt-get update -y &&
apt-get install gcc -y &&
apt-get install unzip -y &&
apt-get install lua5.2 -y &&
apt-get install liblua5.2 -y &&
apt-get install luarocks -y &&
luarocks install basexx &&
apt-get install libssl1.0-dev -y &&
luarocks install luacrypto &&
mkdir src &&
cd src &&
luarocks download lua-cjson &&
luarocks unpack lua-cjson-2.1.0.6-1.src.rock &&
cd lua-cjson-2.1.0.6-1/lua-cjson &&
sed -i 's/lua_objlen/lua_rawlen/g' lua_cjson.c &&
sed -i 's|$(PREFIX)/include|/usr/include/lua5.2|g' Makefile &&
luarocks make &&
luarocks install luajwtjitsi &&
cd

Edit `/etc/prosody/conf.avail/<FQDN>.cfg.lua`

VirtualHost

        authentication = "token"
        app_id="<APP_ID>"
        app_secret="<APP_SECRET>"

Create guest VirtualHost (without requiring auth)

  VirtualHost "guest.<FQDN>"
    authentication = "anonymous"
    modules_enabled = {
            "bosh";
            "pubsub";
            "ping"; -- Enable mod_ping
            "speakerstats";
            "turncredentials";
            "conference_duration";
            "muc_lobby_rooms";
        }
    c2s_require_encryption = false

Edit `/etc/jitsi/meet/<FQDN>-config.js` to enable anonymousdomain

anonymousdomain: 'guest.<FQDN>',

Add to `/etc/jitsi/jicofo/sip-communicator.properties`

org.jitsi.jicofo.auth.URL=EXT_JWT:<FQDN>

Edit `/etc/prosody/prosody.cfg.lua`

admins = { }

component_ports = { 5347 }
component_interface = "0.0.0.0"

standort.digital · January 2, 2021, 8:42pm

Hello,

one question about that code:

<?php
require_once 'vendor/autoload.php';
use \Firebase\JWT\JWT;

$LINK = "https://meet.mydomain.com";
$ROOM = "myroom";

$key = "mysecret";
$payload = array(
    "aud" => "myapp",
    "iss" => "myapp",
    "sub" => "meet.mydomain.com",
    "exp" => time() + (60*60),
    "room" => "$ROOM",
    "moderator" => true,
    "context" => array(
        "user" => array(
            "name" => "username",
            "email" => "username@mydomain.com",
            "avatar" => "https://gravatar.com/avatar/abc123.png"
        )
    )
);

$jwt = JWT::encode($payload, $key);
echo $LINK . '/' . $ROOM . '?jwt=' . $jwt;
echo "\n";
?>

If it is possible to set up there some value to place a password to that conference room who is create?

It will be good if it can be handle by that script to set up that security options… maybe also to enable the lobby?

And is it possible to disable desktop sharing or it is only possible global disable desktop sharing?

Hope someone get some idea and can maybe help.

emrah · January 3, 2021, 7:12am

It’s not possible to set a password or activate the lobby room using JWT now.

Use the following fields to control screen-sharing, recording, streaming features:

$payload = array(
...
...
    "context" => array(
        "user" => array(
         ...
         ...
        ),
        "features" => array(
            "recording" => true,
            "livestreaming" => true,
            "screen-sharing" => true,
        )
    )
);

Enable enableFeaturesBasedOnToken in your /etc/jitsi/meet/YOUR-DOMAIN-config.js for the token based feature control to work

nagmat84 · January 20, 2021, 7:38pm

I found this thread, because I am planning to setup token-based authentication and I was looking for a solution where I get the tokens from. I understood how the tokens should look like in theory and I understood the PHP code. But I do not understand, how I make that PHP code interact with Jitsi/Prosody.

I want to manage my user accounts self-hosted. Do I need to install a full identity provider like Keycloak or is there an more light-weight/easier solution given the fact that user accounts shall be self-hosted (no external identity provider)?

I don’t understand the overall architecture. If I set authentication to internal_hashed, then Jitsi Meet is responsible to create HTML-based user/password dialog and somehow forwards the given credentials to Prosody which perfoms authentication internally. If I enable token-based authentication, does Jitsi still renders the user/password dialog and then interacts with the identity provider (variant 1) or does the client directly interact with the identity provider which is in charge to provide a password dialog (variant 2)? I try to make it clear in two pictures.

Variant 1:

      Client                                                  Jitsi               Identity Provider
        |              <-- HTML password dialog ---             |                        |
        |                                                       |                        |
User enters password                                            |                        |
        |                                                       |                        |
        |        --- HTML POST with Username/Password -->       |                        |
        |                                                       |                        |
        |                                             Create JWT request incl.           |
        |                                               credentials of user              |
        |                                                       |                        |
        |                                                       |  --- JWT request -->   |
        |                                                       |                        |
        |                                                       |               Authorize JWT request
        |                                                       |         Check user credentials and rights
        |                                                       |                Create JWT response
        |                                                       |                        |
        |                                                       |  <-- JWT response ---  |
        |                                                       |                        |
        |                                                  Validate JWT                  |
        |                                                       |                        |              
        |  <-- Let user in (new HTML page or HTTP redirect ---  |                        |

Variant 2:

      Client                                                  Jitsi               Identity Provider
        |       <-- Redirect to Identity Provider ---           |                        |
        |                                                       |                        |
        |  --------------------------- Ask for Authentication ------------------------>  |
        |                                                       |                        |
        |  <------------------------- HTML password dialog ----------------------------  |
        |                                                       |                        |
        |  -------------- HTML POST with Username/Password --------------------------->  |
        |                                                       |                        |
        |                                                       |         Check user credentials and rights
        |                                                       |                Create JWT response
        |                                                       |                        |
        |  <--------------------------------- JWT response ----------------------------  |
        |                                                       |                        |
        |  ------------------- Forward JWT ------------------>  |                        |
        |                                                       |                        |
        |                                                  Validate JWT                  |
        |                                                       |                        |
        |  <-- Let user in (new HTML page or HTTP redirect ---  |                        |

Which variant is correct?

emrah · January 20, 2021, 7:55pm

Jitsi does not interact with the identity provider or even the client for authentication in JWT case. The client connects to jitsi server using a link with a token. Something like that:

https://meet.mydomain.com/room-name?jwt=very-long-jwt-value

None of them

Lightweight solution is OK. After the successful login, redirect the client to jitsi server with a tokenized link.

mod_token_verification (a Prosody plugin) parses the token which is already given in the link and if it’s valid (correctly parsed using the shared secret) allows to login

nagmat84 · January 20, 2021, 8:29pm

Thanks, I believe, I got it. So basically, I set up my own HTML front page with a login form (room name, username, password), post it to my own sever-side script which does the actual authentication and then redirect the client to a room with a tokenized URL. Right?

What do you mean by something like that? Is the query parameter jwt correct and do I only have to replace very-long-jwt-value by a correct JWT based on your PHP script above or is there more to the story?

I assume, I got it. See my summary above. Is there already some lightweight solution which I can use out-of-the box and which you can recommend?

emrah · January 20, 2021, 9:55pm

right

yes

nope

emrah · January 27, 2021, 6:38pm

JWT with PHP

mod_token_affiliation compatible token

packages

apt-get install php-cli composer
composer require firebase/php-jwt

Simple code

jwt.php

<?php
require_once 'vendor/autoload.php';
use \Firebase\JWT\JWT;

$LINK = "https://meet.mydomain.com";
$ROOM = "myroom";

$key = "mysecret";
$payload = array(
    "aud" => "myapp",
    "iss" => "myapp",
    "sub" => "meet.mydomain.com",
    "exp" => time() + (60*60),
    "room" => "$ROOM",
    "context" => array(
        "user" => array(
            "name" => "username",
            "email" => "username@mydomain.com",
            "avatar" => "https://gravatar.com/avatar/abc123.png",
            "affiliation" => "owner",
        ),
        "features" => array(
            "recording" => true,
            "livestreaming" => true,
            "screen-sharing" => true,
        )
    )
);

$jwt = JWT::encode($payload, $key);
echo $LINK . '/' . $ROOM . '?jwt=' . $jwt;
echo "\n";
?>

running

php jwt.php

nagmat84 · January 30, 2021, 11:45am

I finally got token-based authentication working mostly. But I observe some strange effects. My PHP code to create a token looks as follows. The PHP variable $participation is the result of a SQL query. I hope you get the intention based on the variable names:

$jwtPayload = array(
  "aud" => appName,
  "iss" => appName,
  "sub" => domain,
  "nbf" => $participation['start_time'] - (5*60),
  "iat" => time(),
  "exp" => $participation['end_time'] + (60*60),
  "room" => $participation['conference_name'],
  "moderator" => $participation['is_moderator'],
  "context" => array(
    "user" => array(
      "name" => $participation['display_name'],
      "email" => $participation['email'],
      "affiliation" => $participation['is_moderator'] ? "owner" : "member",
    ),
    "features" => array(
      "recording" => $participation['may_record'],
      "livestreaming" => $participation['may_live_stream'],
      "screen-sharing" => $participation['may_share_screen'],
    )
  )
);

The effects I observe are as follows:

A user which only has affiliation member cannot create a room. Such a user must wait until the room has been created by an owner and can join afterwards. → Good, result as expected
However, if the last owner hast left the room, members may stay in the room as long as they want. They are not kicked out. → Bad, result is unexpected
Granting rights to the features recording and livestreaming does not work as expected. The ability to record/livestream seems to be a conference wide setting depending on the values of the last joining user; i.e. if a user joins who must not record/livestream the feature get disabled for everybody, contrary if a user joins who is allowed to record/livestream the feature gets enabled for everybody → Bad, result is unexpected
Everybody is allowed to share his/her screen irrespective of the boolean value of screen-sharing. → Bad, result is unexpected
Everybody seems to have partial rights of a moderator, irrespective of the the boolean value of moderator. For example, everybody can mute everyone else. → Bad, result is unexpected
Contrary, some rights of the moderator are missing for everyone, irrespective of the the boolean value of moderator. For example, the feature “kick out …” does not work at all. → Bad, result is unexpected
The value of user.name is used as a display name for the video stripe at the right, the tile view and for status messages, i.e. Jon Doe has entered/left the room. → Good, result as expected

Update on item 2:

If a user who has been a participant leaves the room, the module Token Owner Party also broadcasts the message “The owner is gone”. Hence, it seems that a user affiliation somehow magically changes from “member” to “owner” at some point of time. The test user has definitely been a “member” in the first place, because the test user was not allowed to create the room.

emrah · January 30, 2021, 2:35pm

I have none of these “bad results” in my system, probably there are some missing steps while installing. You can try jitsi-school-installer

nagmat84 · January 30, 2021, 2:40pm

I am very sure I did not miss any step. And I am not destroying my installation I got so far by running a script which simply floors my current setup. Instead, I would like to understand what is going on.

emrah · January 30, 2021, 2:48pm

Do you have org.jitsi.jicofo.DISABLE_AUTO_OWNER=true in /etc/jitsi/jicofo/sip-communicator.properties

nagmat84 · January 30, 2021, 4:14pm

Yes, I do.

/etc/prosody/conf.d/jitsi.my-domain.tld.cfg.lua

plugin_paths = { "/usr/share/jitsi-meet/prosody-plugins/" }
...
VirtualHost "jitsi.my-domain.tld"
    authentication = "token"
    app_id = "jitsi"
    app_secret = "<my_secret>"
    disable_room_name_constraints = true
    allow_empty_token = false
    ...
    modules_enabled = {
        "bosh";
        "pubsub";
        "ping"; -- Enable mod_ping
        "speakerstats";
        "turncredentials";
        "conference_duration";
        "muc_lobby_rooms";
        "presence_identity";
    }
    c2s_require_encryption = false
    lobby_muc = "lobby.jitsi.my-domain.tld"
    main_muc = "conference.jitsi.my-domain.tld"

Component "conference.jitsi.my-domain.tld" "muc"
    storage = "memory"
    modules_enabled = {
        "muc_meeting_id";
        "muc_domain_mapper";
        "token_verification";
        "token_affiliation";
        "token_owner_party";
    }
   admins = { "focus@auth.jitsi.my-domain.tld" }
   party_check_timeout = 60
   muc_room_locking = false
   muc_room_default_public_jids = true

...

/etc/jitsi/jicofo/sip-communicator.properties

org.jitsi.jicofo.BRIDGE_MUC=JvbBrewery@internal.auth.jitsi.my-domain.tld
org.jitsi.jicofo.auth.URL=EXT_JWT:jitsi.my-domain.tld
org.jitsi.jicofo.DISABLE_AUTO_OWNER=true

/etc/jitsi/meet/jitsi.my-domain.tld-config.js

var config = {
  hosts: {
    domain: 'jitsi.my-domain.tld',
    muc: 'conference.jitsi.my-domain.tld'
  },
  bosh: '//jitsi.my-domain.tld/http-bind',
  clientNode: 'http://jitsi.org/jitsimeet',
  testing: {
    p2pTestMode: false
  },
  enableNoAudioDetection: true,
  enableNoisyMicDetection: true,
  resolution: 720,
  constraints: {
    video: {
      height: {
        ideal: 720,
        max: 1080,
        min: 360
      }
    }
  },
  disableSimulcast: true,
  enableLayerSuspension: true,
  desktopSharingFrameRate: {
    min: 5,
    max: 25
  },
  channelLastN: -1,
  lastNLimits: {
    5:  10,
    10: 5,
    20: 2,
  },
  requireDisplayName: true,
  enableWelcomePage: true,
  defaultLanguage: 'de',
  disableProfile: true,
  enableFeaturesBasedOnToken: true,
  disableThirdPartyRequests: true,
  p2p: {
    enabled: false,
    stunServers: [
      { urls: 'stun:meet-jit-si-turnrelay.jitsi.net:443' }
    ]
  },
  analytics: {
  },
  deploymentInfo: {
  },
  doNotStoreRoom: true,
};

Jitsi-meet-tokens chronicles on Debian Buster

JWT with PHP

packages

Simple code

running

Enable JWT

Edit /etc/prosody/conf.avail/<FQDN>.cfg.lua

Edit /etc/jitsi/meet/<FQDN>-config.js to enable anonymousdomain

Add to /etc/jitsi/jicofo/sip-communicator.properties

Edit /etc/prosody/prosody.cfg.lua

JWT with PHP

packages

Simple code

running

Edit `/etc/prosody/conf.avail/<FQDN>.cfg.lua`

Edit `/etc/jitsi/meet/<FQDN>-config.js` to enable anonymousdomain

Add to `/etc/jitsi/jicofo/sip-communicator.properties`

Edit `/etc/prosody/prosody.cfg.lua`