Want the ability to disable moderator features via the moderator flag in the jwt. Authentication works and the user becomes moderator. Unfortunately the user becomes moderator even if “moderator” = false is set in the JWT
Did you install additional prosody plugins to control moderator role using JWT?
In a default Jitsi install, the context in JWT token does not control user role so you cannot just add a field to promote or demote users to moderators. This is instead controlled by Jicofo which will promote the first user in the meeting to moderator.
You can change this behaviour by disabling that feature in Jicofo and adding custom prosody plugins to implement the behaviour you want.
If you elaborate further on what you are trying to achieve, someone might be able to point you to the right direction.
In a non-docker setup, I would set both jicofo.authentication.enabled and jicofo.conference.enable-auto-owner to false so jicofo does not promote anyone to moderator.
I would then use something like this to promote users based on a value in their JWT:
That plugins looks at context.user.affiliation field to determine if a user should be moderator, but it should be relatively trivial to change that to context.user.moderator.
For docker, there is the ENABLE_AUTO_OWNER to disable Jicofo owner, but looks like jicofo.authentication.enabled is hardcoded to true if you enable auth.
I’m afraid I don’t use docker so I have no idea how best to deal with this. My guess is you either customise the config further to disable auth in Jicofo, or you leave it be and extend the plugin further to block Jicofo from promoting or actively demote users that do not have the correct flag.
So this was also solved by updating the Jitsi images. However we noticed something strange
Moderator get their name set via jwt and they are allowed to change their displayname in the gui. The display name is changed for the moderator but it remains the jwt display name for guest in the meeting
Moderator → “JWT name” → Change name manually → “New name”
Guest → sets its own displayname → sees the “JWT name” of moderator
One solution could be to disable the ability to set displayname, but that would not be wanted behavior as we want guests to be able to set their displayname
It’s not perfect, since when a JWT user updates their name in the UI they will still see the name change locally, but others will still see the original name. Which is why we use it in conjunction with readOnlyName config option, but this is only viable if all users use JWT.
That really should not happen. No idea why that’s happening in your case