This PR reduces the impact of #8618 by increasing hardcoded timeout from 7s to 60s
A subsequent PR is going to be sent by @gustavotrott to:
-> Make this timeout configurable;
-> Add a log telling that timeout happened
Moderators are able to send a message to the meeting's guest lobby. This new
event reaches bbb-web and is sent to the guest user with her/his status response
while polling. All guest users that are waiting for acceptance will be able to
read this message.
enableGuestLobbyMessage is disabled by default.
Pad exporter uses this same location to serve pad's downloaded content
but the the match was failing because padId is not the last element
of the URL on that scenario.
Pattern follows /pad/p/<padID>[/export/(format)]?<query>.
Associate pads with meetings so session validation is restricted to the
meeting's valid session tokens.
Meteor will dispatch new redis events on shared notes and closed captions
pads creation. This event will go through apps and reach web to populate
a new meeting's pad collection that contains all valid pad id's for that
session. Nginx will use this collection to check if the user's session token
belongs to the pad's authorized users.
Besides these modifications, an extra change will be needed at notes.nginx.
Location /pad/p/ needs to change it's auth_request:
from /bigbluebutton/connection/checkAuthorization;
to /bigbluebutton/connection/validatePad;
The message/event UserLeftVoiceConfToClientEvtMsg is used when user leaves mic and listenonly, but it only sets to false the 'voiceJoined' (which represents the <hasVoiceVoiceJoined> property in BBB's XML API.
We now also set to false the 'listeningOnly' (which represents the <isListeningOnly> property in BBB's XML API). Setting both to false is not a problem, once 'MIC' and 'ListenOnly' states are mutually exclusives
Fixes#10852
This patch includes two improvements made for bbb-web. It tries to better isolate
the sessionToken's handling and session's validation, including logs for each one of
these steps; and removes maxParticipats control from registered users (that are no
longer removed from bbb-web collections) binding it to joined users or users that
reached the enter API call. The following adds more details about this last one:
User's regular flow to join a meeting goes around an API join call -> redis register event ->
redirect to client page -> API enter call -> redis join event. When the guest policy is ASK_MODERATOR,
non-moderators are registered and redirected to a guest lobby that polls for her/his guest status and
only enters the meeting after a moderator approval.
Using registered users as control to check how many participants are in a meeting is problematic because
non-approved guests are counted as participants and bbb-web has to find out when to ditch registered users
records to make a seat in a meeting available again. In other words, a meeting with maxParicipants
of 5 can get it's joins locked with a moderator and 4 waiting guests or bbb-web can wrongly drop a registered
user record on a reconnection inducing weird 401 responses from the API.
This change proposes to control maxParticipants both at join and enter API calls monitoring the number
of redis joined users. This also includes an extra buffer to capture users that called the enter API but
still don't have an user joined event.
User left events are now handled different holding the user data before removing from the joined users collection
and only releasing after verifying that the user didn't reconnected.
Both user left timeout `usersTimeout` and entered user timeout `enteredUsersTimeout` can be configured at properties.
