greenlight GIT-2008: Fixed recording consent circumventing (Fixes #2008).

Description

Enabling the Require Room Owner and Joiner Consent to Recording feature in Site settings>Settings in the Organization section will result for rooms with the setting Allow room to be recorded enabled to have a consent on their join page. Any user that wants to attend one of the room sessions has to accept the consent. Some scenarios makes this consent vulnerable to circumventing.

Scenario 1

User enters the waiting page of a room without recording enabled.
Room owner (or anyone with the right permissions) allow recordings for the room and starts a session.
User joins the meeting without accepting the recording consent.

Scenario 2

User access the join page for a room without recording enabled.
Room owner (or anyone with the right permission) enables recording and start the room.
User joins the session without accepting the recording consent.

Scenario 3

Room owner (or anyone with the right permission) enables recording for a room and starts a session.
Room owner (or anyone with the right permission) disable recording for the room.
User access the join page and joins the room without accepting the recording consent.

Testing Steps

All of the mentioned scenarios above.

Solution explanation

A room will have a new attribute is_starting defining wither is it starting or not starting. Upon the creating of a room session, the room will be marked as starting and after the creation completes (successfully or by an error) it will be marked as not starting after 5 seconds by a job (to wait optimistically for the room to run on the BBB server in case it started successfully) click here, here and here. Whenever a room that has been created is running or starting, it will conserve some of its settings upon any attempt to update them. The conserve_settings method will take a list of settings and conserve them dynamically in such cases (meaning that changing that list can be done upon method call and it will dynamically iterate over them and do the rest) click here. This will prevent altering some critical settings when the room is running or starting on server side answering Scenario 3. For UI consistency, any html element in the create room modal having the attribute data-disable-while-running will be automatically disabled when the room is running or starting and it have the room state added to its settings that will be sent by the room_settings action upon fetching them on client side click here, here and here. Without the starting state a room will still be vulnerable to Scenario 3 because of the time required by BBB to mark the room as running.

For Scenario 1 & 2 : The recording consent is now a form input, meaning that its value will be passed to the controller that will check if the consent has to be accepted and make sure that it is otherwise it redirects users back to join page with the proper alert message forcing them to accept the consent when it has too click here and here. Accepting the consent will not be conserved upon entering the waiting channel since the controller action checked that the request is legit and rendered the waiting page which in its turn upon starting the room will simply make an xhr request to join the user leading to sending it without the consent being accepted. For that the wait page will have a hidden html element that conserves the user choice for the consent and on client side it will make sure to extract that value and send it back to the controller upon joining click here and here.