Moderator comes with jwt in url and guests enter without jwt and are required to set their displayname.
The moderator sees the correct displayname for all participants but guests only sees “Fellow Jitster” for the moderator. Their set name is displayed correctly.
Is there a way to display the actual name instead of “Fellow Jitster” for guests and other moderators?
Did you set context.user.name in JWT? That would be what is used for the display name of a user authenticated with JWT.
If you have, then something’s wrong. “Fellow Jitster” is the default name used when a user does not have name set.
Yep, context.user.name is appended correctly to the moderators session and displayed for the moderator. But guests see the moderators name as “Fellow Jitster”
I am wondering if this could be an issue with “this is not intended to work” scenario with mixing JWT vs. guests entering without JWT. Remember seeing a issue on this on github that damencho commented on.
To get guests to even be able to access rooms we need to have this set:
JWT_ENABLE_DOMAIN_VERIFICATION = false
JWT with guest users should work as usual if you set allow_empty_token = true. IIRC, things get a bit messed up when you use JWT with guest domain.
I’m guessing you’re using docker? I believe you can use JWT_ALLOW_EMPTY to set that.
That should only really affect how JWT tokens are verified. With domain verification enabled, it will check that the sub claim matches your domain (or tenant name if multi-tenant room is used). I don’t see how this would affect guest access.
Not sure why, but updating the Jitsi images seems to have solved this scenario. Scary and good at the same time 
So the issue has re-appeared and we believe we the issue lies with frozen_nick module and maybe a combo with our set up
If we disable frozen_nick the display name shown for guests is correct(JWT name). If we have it enabled the JWT user is displayed as “Fellow jitster”.
What could make frozen_nick to make this issue appear?
That’s odd indeed. No idea what might cause that.
Perhaps try logging out the value of event.origin.jitsi_meet_context_user['name'] in the module to see if name is correctly set? If name is not shown, then we know the issue is that jitsi_meet_context_user is not being set. If the name is show, then we know the issue might be with the presense message.
We will give this a try, what would be the method to log this out? Can it be sent to the prosody log?
Something like this:
module:log("info", "Name %s", event.origin.jitsi_meet_context_user['name']);
When executed, that will write to prosody logs prefixed by the module name.
So adding the debug line “fixed” the issue, we have not been able to reproduce the behavior again 
Will try removing the debug line and see if the issue reappears, but at least now we have a quick fix 
