The Jitsi JWT tokens are presumably checked for expiration date (actually, I should make sure that's true.) But that's only checked at login time. If you log in with a token that has three minutes of valid time and hang out for five minutes, you don't get kicked off (I just tried it.)
So: limited-time JWT tokens are a way to keep people from logging in when they shouldn't. But they're not a way to make sure people don't overstay their allotted time on a channel.
This means the chat admin server is going to need to be fairly active about scouting who is on what channel if we want people definitely off.
This means tokens are going to effectively be one-time logins for the channel -- we'll want them to have some very short expiration like 30 seconds. If Jitsi won't keep you from staying connected with an expired token, it makes much more sense for us to not hand out highly-abusable long-duration tokens. We'd prefer to hand out moderately-abusable short-duration tokens.
At that point, if we want to boot somebody from the conference, the method will be:
tell SkotOS to stop handing them JWT tokens
(optional) scan through all the Jitsi channels and kick them out
wait 30 seconds for all their tokens to expire
(mandatory) scan through all the Jitsi channels and actually kick them out, now that it will stick
Since this method wants a more assertive chat_admin_server (needs to scan rooms, probably by connecting to them) this will pretty certainly require a headless browser (probably Chrome via Puppet) using the Jitsi APIs from JS, and the admin server will be a full-on user, though probably one that doesn't send video or audio. Like, it'll show up in the logged-in user list briefly as it connects to your Jitsi room to see who's logged in.
It won't need to connect to all rooms all the time, though. Only when kicking people, or if we want it to monitor who's in rooms to prevent overstaying an expired JWT token. But periodic sweeps should be fine -- no need for continuous connection.
The Jitsi JWT tokens are presumably checked for expiration date (actually, I should make sure that's true.) But that's only checked at login time. If you log in with a token that has three minutes of valid time and hang out for five minutes, you don't get kicked off (I just tried it.)
So: limited-time JWT tokens are a way to keep people from logging in when they shouldn't. But they're not a way to make sure people don't overstay their allotted time on a channel.
This means the chat admin server is going to need to be fairly active about scouting who is on what channel if we want people definitely off.
This means tokens are going to effectively be one-time logins for the channel -- we'll want them to have some very short expiration like 30 seconds. If Jitsi won't keep you from staying connected with an expired token, it makes much more sense for us to not hand out highly-abusable long-duration tokens. We'd prefer to hand out moderately-abusable short-duration tokens.
At that point, if we want to boot somebody from the conference, the method will be:
Since this method wants a more assertive chat_admin_server (needs to scan rooms, probably by connecting to them) this will pretty certainly require a headless browser (probably Chrome via Puppet) using the Jitsi APIs from JS, and the admin server will be a full-on user, though probably one that doesn't send video or audio. Like, it'll show up in the logged-in user list briefly as it connects to your Jitsi room to see who's logged in.
It won't need to connect to all rooms all the time, though. Only when kicking people, or if we want it to monitor who's in rooms to prevent overstaying an expired JWT token. But periodic sweeps should be fine -- no need for continuous connection.