Docker-jitsi-meet: ENABLE_GUESTS=1 not working with AUTH_TYPE=jwt?

[D3473R]

I have set up jitsi to use the jwt auth type and i can join a room with a valid jwt token. However, if I want to join as a guest I'm getting the login promt and not the Waiting for the host promt
I deleted the persistent jitsi config folder and ENABLE_GUESTS=1 is set in the config.
Does anyone has jwt with guests running successfully?

Regards,
D3473R

[saghul]

@damencho I think this doesn't really work, does it?

[damencho]

In the case of jwt there is a config allow_empty_token if it is true it allows guests to connect without specifying a token.

[saghul]

Aha. We even have a variable for that: JWT_ALLOW_EMPTY. @D3473R try setting JWT_ALLOW_EMPTY to 1.

I wonder if we should deprecate this and use ENABLE_GUESTS. WDYT @damencho ?

[damencho]

Yeah, make sense, sounds like the same.

[D3473R]

The password required promt is still coming up for me after adding JWT_ALLOW_EMPTY=1 in the .env file, i deleted the config folder and recreated the containers.

Prosody log:

prosody_1  | muc.meet.jitsi:token_verification  warn    WARNING - empty tokens allowed
prosody_1  | meet.jitsi:auth_token              warn    WARNING - empty tokens allowed
...
prosody_1  | guest.meet.jitsi:saslauth                 warn     SASL succeeded but username was invalid

[saghul]

Are you running the last version of the containers?

Also, can you paste the entire generated prosody config?

[D3473R]

I am running the latest tag from Dockerhub.

Wich files do you need?

conf.d/jitsi-meet.cfg.lua

admins = { "[email protected]" }
plugin_paths = { "/prosody-plugins/", "/prosody-plugins-custom" }
http_default_host = "meet.jitsi"












VirtualHost "meet.jitsi"


    authentication = "token"
    app_id = "jitsi"
    app_secret = "XXX"
    allow_empty_token = true




    ssl = {
        key = "/config/certs/meet.jitsi.key";
        certificate = "/config/certs/meet.jitsi.crt";
    }
    modules_enabled = {
        "bosh";
        "pubsub";
        "ping";


    }

    c2s_require_encryption = false


VirtualHost "guest.meet.jitsi"
    authentication = "anonymous"
    c2s_require_encryption = false


VirtualHost "auth.meet.jitsi"
    ssl = {
        key = "/config/certs/auth.meet.jitsi.key";
        certificate = "/config/certs/auth.meet.jitsi.crt";
    }
    authentication = "internal_plain"

Component "internal-muc.meet.jitsi" "muc"
    modules_enabled = {
        "ping";

    }
    storage = "memory"
    muc_room_cache_size = 1000

Component "muc.meet.jitsi" "muc"
    storage = "memory"
    modules_enabled = {


        "token_verification";

    }

Component "focus.meet.jitsi"
    component_secret = "s3cr37"

[saghul]

Hum, your config looks OK. Can you paste the prosody logs?

[saghul]

Also, @aaronkvanmeerten do you have any ideas?

[D3473R]

Sure:

prosdy.log

Attaching to docker-jitsi-meet_prosody_1
prosody_1  | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
prosody_1  | [s6-init] ensuring user provided files have correct perms...exited 0.
prosody_1  | [fix-attrs.d] applying ownership & permissions fixes...
prosody_1  | [fix-attrs.d] done.
prosody_1  | [cont-init.d] executing container initialization scripts...
prosody_1  | [cont-init.d] 01-set-timezone: executing... 
prosody_1  | [cont-init.d] 01-set-timezone: exited 0.
prosody_1  | [cont-init.d] 10-config: executing... 
prosody_1  | Adding user `prosody' to group `sasl' ...
prosody_1  | Adding user prosody to group sasl
prosody_1  | Done.
prosody_1  | Generating RSA private key, 2048 bit long modulus
prosody_1  | .........+++++
prosody_1  | ..............................+++++
prosody_1  | e is 65537 (0x010001)
prosody_1  | Choose key size (2048): Key written to /config/data/meet.jitsi.key
prosody_1  | Please provide details to include in the certificate config file.
prosody_1  | Leave the field empty to use the default value or '.' to exclude the field.
prosody_1  | countryName (GB): localityName (The Internet): organizationName (Your Organisation): organizationalUnitName (XMPP Department): commonName (meet.jitsi): emailAddress ([email protected]): 
prosody_1  | Config written to /config/data/meet.jitsi.cnf
prosody_1  | Certificate written to /config/data/meet.jitsi.crt
prosody_1  | 
prosody_1  | Generating RSA private key, 2048 bit long modulus
prosody_1  | ......................................+++++
prosody_1  | .............................................................................................................+++++
prosody_1  | e is 65537 (0x010001)
prosody_1  | Choose key size (2048): Key written to /config/data/auth.meet.jitsi.key
prosody_1  | Please provide details to include in the certificate config file.
prosody_1  | Leave the field empty to use the default value or '.' to exclude the field.
prosody_1  | countryName (GB): localityName (The Internet): organizationName (Your Organisation): organizationalUnitName (XMPP Department): commonName (auth.meet.jitsi): emailAddress ([email protected]): 
prosody_1  | Config written to /config/data/auth.meet.jitsi.cnf
prosody_1  | Certificate written to /config/data/auth.meet.jitsi.crt
prosody_1  | 
prosody_1  | [cont-init.d] 10-config: exited 0.
prosody_1  | [cont-init.d] done.
prosody_1  | [services.d] starting services
prosody_1  | saslauthd[254] :num_procs  : 5
prosody_1  | saslauthd[254] :mech_option: /etc/saslauthd.conf
prosody_1  | saslauthd[254] :run_path   : /var/run/saslauthd
prosody_1  | saslauthd[254] :auth_mech  : ldap
prosody_1  | saslauthd[254] :mmaped shared memory segment on file: /var/run/saslauthd/cache.mmap
prosody_1  | saslauthd[254] :bucket size: 96 bytes
prosody_1  | saslauthd[254] :stats size : 36 bytes
prosody_1  | saslauthd[254] :timeout    : 28800 seconds
prosody_1  | saslauthd[254] :cache table: 985828 total bytes
prosody_1  | saslauthd[254] :cache table: 1711 slots
prosody_1  | saslauthd[254] :cache table: 10266 buckets
prosody_1  | startup             info  Hello and welcome to Prosody version 0.11.2
prosody_1  | saslauthd[254] :flock file opened at /var/run/saslauthd/cache.flock
prosody_1  | saslauthd[254] :using accept lock file: /var/run/saslauthd/mux.accept
prosody_1  | saslauthd[254] :master pid is: 0
prosody_1  | saslauthd[254] :listening on socket: /var/run/saslauthd/mux
prosody_1  | saslauthd[254] :using process model
prosody_1  | saslauthd[254] :forked child: 262
prosody_1  | saslauthd[254] :forked child: 263
prosody_1  | saslauthd[254] :forked child: 264
prosody_1  | saslauthd[254] :forked child: 265
prosody_1  | saslauthd[254] :acquired accept lock
prosody_1  | [services.d] done.
prosody_1  | startup             info  Prosody is using the select backend for connection handling
prosody_1  | meet.jitsi:auth_token  warn    WARNING - empty tokens allowed
prosody_1  | portmanager            info   Activated service 's2s' on [::]:5269, [*]:5269
prosody_1  | portmanager            info   Activated service 'http' on [::]:5280, [*]:5280
prosody_1  | portmanager            info   Activated service 'https' on no ports
prosody_1  | portmanager            info   Activated service 'c2s' on [::]:5222, [*]:5222
prosody_1  | portmanager            info   Activated service 'legacy_ssl' on no ports
prosody_1  | portmanager            info   Activated service 'component' on [*]:5347
prosody_1  | muc.meet.jitsi:token_verification  warn    WARNING - empty tokens allowed
prosody_1  | c2s55ff04ae2230                    info   Client connected
prosody_1  | jcp55ff048940e0                    info   Incoming Jabber component connection
prosody_1  | focus.meet.jitsi:component         info   External component successfully authenticated
prosody_1  | c2s55ff0479b100                    info   Client connected
prosody_1  | c2s55ff04ae2230                    info   Stream encrypted (TLSv1.2 with ECDHE-RSA-AES256-GCM-SHA384)
prosody_1  | c2s55ff04ae2230                    info   Authenticated as [email protected]
prosody_1  | c2s55ff0479b100                    info   Stream encrypted (TLSv1.2 with ECDHE-RSA-AES256-GCM-SHA384)
prosody_1  | c2s55ff0479b100                    info   Authenticated as [email protected]
prosody_1  | mod_bosh                           info   New BOSH session, assigned it sid 'd4d06fa3-18d6-4ddd-acb4-c7e23c311324'
prosody_1  | boshd4d06fa3-18d6-4ddd-acb4-c7e23c311324  info    Authenticated as [email protected]
prosody_1  | mod_bosh                                  info    New BOSH session, assigned it sid '9456d213-14d7-408b-9f3c-ac527245e883'
prosody_1  | guest.meet.jitsi:saslauth                 warn SASL succeeded but username was invalid
prosody_1  | bosh9456d213-14d7-408b-9f3c-ac527245e883  info    BOSH client disconnected: session close
prosody_1  | boshd4d06fa3-18d6-4ddd-acb4-c7e23c311324  info    BOSH client disconnected: session close

[saghul]

SASL succeeded but username was invalid

This looks like the reason, even though I don’t know why.

[aaronkvanmeerten]

My understanding of the guests feature is minimal, but as far as I understood it the Jitsi Meet client will act differently when informed of a guest or anonymous access point, and will prompt for a password in this case. In order to allow empty JWTs but not be prompted for a password, we probably need to not advertise the guest prosody endpoint to jitsi-meet, and we don't need it defined in prosody either. So maybe the best way to say it is: don't use ENABLE_GUESTS=1 in this case, but instead use AUTH_TYPE=jwt with JWT_ALLOW_EMPTY=1

[D3473R]

With setting ENABLE_GUESTS=0 and JWT_ALLOW_EMPTY=1 now everyone can join directly without providing a valid token but there is no Waiting for the host ... Popup shown.

[aaronkvanmeerten]

I see: I misread your original comment: I'm not 100% sure how to accomplish that behavior with the current scheme. The behavior you describe here is exactly how we'd expect these config options to work together at the moment. I'll raise this today with the team and see what we can come up with.

[Jaffex]

I'm currently trying to achieve the exact same behavior as @D3473R.
My config also looks exactly the same.

Any news on this issue? Were you able to solve it @D3473R?

[D3473R]

No, JWT with Guest Access is not possible at the moment afaik.
I've build a Keycloak Connector which gives you the ability to create random rooms for guests.
If you are using Keycloak too this could help: https://github.com/D3473R/jitsi-keycloak

EDIT: @aaronkvanmeerten a valid_from and valid_to option in the JWT would be awesome. Then one could create sharable invite links to a room with a time limit. Or schedule a meeting in the future and already send out the invites.

[saghul]

I believe this was solved in Jitsi Meet, so building the latest unstable images would be a good way to test, if anyone is up for it. See: https://github.com/jitsi/jitsi-meet/pull/5025

[Jaffex]

I didn't build the unstable image yet but I added just the line from the commit behind jitsi/jitsi-meet#5025 into my mod_auth_token.lua. I know that's a bit of a hack - I just wanted to confirm that one additional line fixes the problem perfectly!

[TMHBOFH]

with the latest docker image it works
Thanks alot

[D3473R]

with the latest docker image it works
Thanks alot

Just pulled the latest docker images, and it is working perfect now.
Thank you so much guys 🎉

[HobieCat]

with the latest docker image it works
Thanks alot

Hello there,
I'm trying to have the same behaviour that i recap for clarity:

1. User John has a link to a room without the JWT: he must not be able to create the room, but can join as a Guest after the room has been created by someone having the same link with the JWT.
2. User Sue has a link to the same room as John, with the JWT: she will create the room and join as Member and after, when John comes back he will be able to join as a Guest.

My test were all with ENABLE_AUTH=1 and AUTH_TYPE=jwt, results are:

|ENABLE_GUEST|JWT_ALLOW_EMPTY|What happens
-------------------------:|-------------------------------:|---
|0|0|Sue creates the room, but John always has the login form: before and after room creation
|0|1|John creates the room before Sue does. After Sue joins, both are moderators
|1|0|Sue creates the room, but John always has the login form: before and after room creation
|1|1|John creates the room before Sue does. After Sue joins, both are moderators

This is driving my crazy for the whole day, may I please ask you to share your working configuration? What am I missing?

Thank you, cheers

[vnathn]

can i use AUTH_TYPE=jwt,internal_plan at a time?

[felixng1028]

with the latest docker image it works
Thanks alot

Hello there,
I'm trying to have the same behaviour that i recap for clarity:

1. User John has a link to a room without the JWT: he must not be able to create the room, but can join as a Guest after the room has been created by someone having the same link with the JWT.
2. User Sue has a link to the same room as John, with the JWT: she will create the room and join as Member and after, when John comes back he will be able to join as a Guest.

My test were all with ENABLE_AUTH=1 and AUTH_TYPE=jwt, results are:

ENABLE_GUEST JWT_ALLOW_EMPTY What happens
0 0 Sue creates the room, but John always has the login form: before and after room creation
0 1 John creates the room before Sue does. After Sue joins, both are moderators
1 0 Sue creates the room, but John always has the login form: before and after room creation
1 1 John creates the room before Sue does. After Sue joins, both are moderators
This is driving my crazy for the whole day, may I please ask you to share your working configuration? What am I missing?

Thank you, cheers

same issue here.

[Jaffex]

Here's what I added to the configuration which works with the latest docker image:
File .env:

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=jwt
JWT_APP_ID=SomeApp
JWT_APP_SECRET=averysecretphrase

In my use case, I open all Jitsi Meetings via a RocketChat instance. Which just knows the JWT_APP_ID and the JWT_APP_SECRET - but this should also work if you create the tokens by other means.

Please also note that while staying in the example of John and Sue, in this setting, John will be able to "join" the room but will be told to wait for a moderator. Once Sue joins, she will start the meeting because she joins as a moderator.