Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(transcriptions,recording): Allows non moderators with features to dial, record or transcribe. #15074

Merged
merged 14 commits into from
Sep 13, 2024

Conversation

damencho
Copy link
Member

No description provided.

@damencho damencho requested a review from bgrozev August 30, 2024 14:26
@damencho
Copy link
Member Author

Hum, I'm getting forbidden when I'm a moderator without a token. It still needs more testing.

@damencho
Copy link
Member Author

damencho commented Sep 3, 2024

Hum, I'm getting forbidden when I'm a moderator without a token. It still needs more testing.

It is fixed now.

bgrozev
bgrozev previously requested changes Sep 4, 2024
/**
* The dial command to use for starting a transcriber.
*/
const TRANSCRIBER_DIAL_COMMAND = 'jitsi_meet_transcribe';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest something other than "command" which we already used for other things. I looked it up and we use "number" (in the ljm API), "to" (in the rayo xml), and "destination" (in our java rayo impl).


-- if current user is not allowed, but was granted moderation by a user
-- that is allowed by its features we want to allow it
local is_granting_allowed = false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you care about the distinction of whether it was "naturally" allowed or because the features were granted. I suggest simplifying to something like

local is_allowed = is_feature_allowed(session.jitsi_meet_context_features, feature) or
is_feature_allowed(session.granted_jitsi_meet_context_features, feature)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I want to check that only if there are features set.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A right, we have changed behavior of is_feature_allowed, so this will work.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, this is not correct as it will check for moderator rights if you have the feature = "false".
so we have two cases, are features available and is the feature set to false.

then
if not session.jitsi_meet_context_features and not session.granted_jitsi_meet_context_features then
-- we need to check for moderator rights
-- when there are no features and the occupant is moderator we allow recording
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't we extract the set of features in a central place? I think it would be less error prone. For example, we can do it at token verification time. We can read the token and set the features accordingly. If the moderator flag is raised and no features are specified we can populate the defaults. That would also be the place to set features to an empty set when no token is present. Then, everywhere else we can assume that the set of features is set accordingly, and we don't have to know the details.

This whole section would simplify to:

local is_allowed = ...
if ~is_allowed then
  module:log(...)
  session.send(st.error_reply(stanza, "auth", "forbidden"));
end  

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do not have a common rule for defining moderator, and ther rules we use in deploments are outside of this project.
The extraction time of features is before we know whether it is a moderator.

Copy link
Member

@bgrozev bgrozev Sep 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Then can we extract a utility function like is_feature_allowed(feature, features, granted_features, isModerator)? So that all that logic is consistent and in one place?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I addressed that now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We lost some small optimizations cause before we were looking up the room to search for the occupant to check the role only when needed.

resources/prosody-plugins/mod_filter_iq_rayo.lua Outdated Show resolved Hide resolved
local data, key, occupant, session = event.data, event.key, event.actor, event.session;

if occupant.role == 'moderator' then
return data;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the case of a moderator which doesn't have transcription rights?

@@ -37,9 +37,11 @@ class StartRecordingDialogContent extends AbstractStartRecordingDialogContent {
* @returns {React$Component}
*/
render() {
const _renderRecording = this.props._isModerator || this.props._hasRecordingFeature;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar as above, it should be based on the content of features, with the moderator flag only being used to infer defaults

@@ -267,8 +267,8 @@ export function getRecordButtonProps(state: IReduxState) {

if (localRecordingEnabled) {
visible = true;
} else if (isModerator) {
visible = recordingEnabled ? isJwtFeatureEnabled(state, 'recording', true) : false;
} else if (isModerator || isJwtFeatureEnabled(state, 'recording', false, false)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above

if (localParticipantIsModerator && !isInBreakoutRoom) {
visible = liveStreamingEnabled ? liveStreamingEnabledInJwt : false;
if (!isInBreakoutRoom) {
visible = liveStreamingEnabled ? localParticipantIsModerator || liveStreamingEnabledInJwt : false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to above, I think

if (enabled && conference?.getTranscriptionStatus() === 'off') {
const featureAllowed = isJwtFeatureEnabled(getState(), 'transcription', false, false);

if (isLocalParticipantModerator(state) || featureAllowed) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above


if (!transcription?.enabled) {
return false;
}

if (isJwtTranscribingEnabled) {
if (isLocalParticipantModerator(state) || isJwtTranscribingEnabled) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above

@damencho damencho force-pushed the non-moderator-features branch 3 times, most recently from c373ff7 to 47ee211 Compare September 4, 2024 23:02
or not is_feature_allowed(session.jitsi_meet_context_features,
(jibri.attr.recording_mode == 'file' and 'recording' or 'livestreaming')
) then
if token == nil or not is_allowed then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need to check token here? What are we supposed to do if the user is a moderator with no token? Or if the user was granted features, but has no token?

If some form of check for token is necessary can we move it to is_feature_allowed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are we supposed to do if the user is a moderator with no token?

The case when you are not using jwt for authentication, but you are moderator. Hum but this is explicit check if there is no token ... I will drop it.

Or if the user was granted features, but has no token?

Most of the cases are like this, you grant moderation to guests that has no token.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@@ -20,10 +20,10 @@ export const MEET_FEATURES = {

/**
* A mapping between jwt features and toolbar buttons keys.
* We don't need recording in here, as it will disable and local recording.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I understand the message. Can you elaborate?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cause even when feature recording(the feature is for server-side recording) is disabled you see local recording.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or I'm wrong ... ?

})) {
&& !_isInBreakoutRoom
&& liveStreaming?.enabled
&& liveStreamingAllowed) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did we remove the isLiveStreamingButtonVisible function isn't the condition the same here and in the component?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, as it depends on the isModerator only if the token is missing or there are no features in the token.

@damencho damencho dismissed bgrozev’s stale review September 13, 2024 15:35

The changes requested have been implemented.

@damencho damencho merged commit b3742a3 into master Sep 13, 2024
9 checks passed
@damencho damencho deleted the non-moderator-features branch September 13, 2024 16:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants