riot-web/src/vector/jitsi/index.ts

395 lines
15 KiB
TypeScript
Raw Normal View History

Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
/*
Copyright 2020 New Vector Ltd.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/
2021-06-30 14:28:31 +02:00
import { KJUR } from 'jsrsasign';
import {
2020-09-24 21:25:59 +02:00
IOpenIDCredentials,
IWidgetApiRequest,
VideoConferenceCapabilities,
2020-10-01 04:09:42 +02:00
WidgetApi,
} from "matrix-widget-api";
2020-10-01 04:09:42 +02:00
import { ElementWidgetActions } from "matrix-react-sdk/src/stores/widgets/ElementWidgetActions";
import { logger } from "matrix-js-sdk/src/logger";
import { IConfigOptions } from "matrix-react-sdk/src/IConfigOptions";
import { SnakedObject } from "matrix-react-sdk/src/utils/SnakedObject";
import { getVectorConfig } from "../getconfig";
// We have to trick webpack into loading our CSS for us.
require("./index.scss");
2020-09-08 10:44:11 +02:00
const JITSI_OPENIDTOKEN_JWT_AUTH = 'openidtoken-jwt';
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
// Dev note: we use raw JS without many dependencies to reduce bundle size.
// We do not need all of React to render a Jitsi conference.
declare let JitsiMeetExternalAPI: any;
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
let inConference = false;
// Jitsi params
let jitsiDomain: string;
let conferenceId: string;
let displayName: string;
let avatarUrl: string;
let userId: string;
let jitsiAuth: string;
let roomId: string;
2020-09-24 21:25:59 +02:00
let openIdToken: IOpenIDCredentials;
let roomName: string;
let startAudioOnly: boolean;
let isVideoChannel: boolean;
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
let widgetApi: WidgetApi;
let meetApi: any; // JitsiMeetExternalAPI
let skipOurWelcomeScreen = false;
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
const ack = (ev: CustomEvent<IWidgetApiRequest>) => widgetApi.transport.reply(ev.detail, {});
(async function() {
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
try {
// Queue a config.json lookup asap, so we can use it later on. We want this to be concurrent with
// other setup work and therefore do not block.
const configPromise = getVectorConfig('..');
// The widget's options are encoded into the fragment to avoid leaking info to the server.
const widgetQuery = new URLSearchParams(window.location.hash.substring(1));
// The widget spec on the other hand requires the widgetId and parentUrl to show up in the regular query string.
const realQuery = new URLSearchParams(window.location.search.substring(1));
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
const qsParam = (name: string, optional = false): string => {
const vals = widgetQuery.has(name) ? widgetQuery.getAll(name) : realQuery.getAll(name);
if (!optional && vals.length !== 1) {
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
throw new Error(`Expected singular ${name} in query string`);
}
return <string>vals[0];
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
};
// If we have these params, expect a widget API to be available (ie. to be in an iframe
// inside a matrix client). Otherwise, assume we're on our own, eg. have been popped
// out into a browser.
const parentUrl = qsParam('parentUrl', true);
const widgetId = qsParam('widgetId', true);
const theme = qsParam('theme', true);
if (theme) {
document.body.classList.add(`theme-${theme.replace(" ", "_")}`);
}
2020-07-13 18:32:17 +02:00
// Set this up as early as possible because Element will be hitting it almost immediately.
let readyPromise: Promise<[void, void]>;
if (parentUrl && widgetId) {
const parentOrigin = new URL(qsParam('parentUrl')).origin;
widgetApi = new WidgetApi(qsParam("widgetId"), parentOrigin);
widgetApi.requestCapabilities(VideoConferenceCapabilities);
readyPromise = Promise.all([
2020-09-24 21:25:59 +02:00
new Promise<void>(resolve => {
widgetApi.once(`action:${ElementWidgetActions.ClientReady}`, ev => {
2020-09-24 21:25:59 +02:00
ev.preventDefault();
widgetApi.transport.reply(ev.detail, {});
resolve();
});
}),
new Promise<void>(resolve => {
widgetApi.once("ready", () => resolve());
}),
]);
widgetApi.start();
} else {
logger.warn("No parent URL or no widget ID - assuming no widget API is available");
}
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
// Populate the Jitsi params now
jitsiDomain = qsParam('conferenceDomain');
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
conferenceId = qsParam('conferenceId');
displayName = qsParam('displayName', true);
avatarUrl = qsParam('avatarUrl', true); // http not mxc
userId = qsParam('userId');
jitsiAuth = qsParam('auth', true);
roomId = qsParam('roomId', true);
roomName = qsParam('roomName', true);
startAudioOnly = qsParam('isAudioOnly', true) === "true";
isVideoChannel = qsParam('isVideoChannel', true) === "true";
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
// We've reached the point where we have to wait for the config, so do that then parse it.
const instanceConfig = new SnakedObject<IConfigOptions>((await configPromise) ?? <IConfigOptions>{});
const jitsiConfig = instanceConfig.get("jitsi_widget") ?? {};
skipOurWelcomeScreen = (new SnakedObject<IConfigOptions["jitsi_widget"]>(jitsiConfig))
.get("skip_built_in_welcome_screen") || isVideoChannel;
// If we're meant to skip our screen, skip to the part where we show Jitsi instead of us.
// We don't set up the call yet though as this might lead to failure without the widget API.
if (skipOurWelcomeScreen) {
toggleConferenceVisibility(true);
}
if (widgetApi) {
2020-09-22 17:01:55 +02:00
await readyPromise;
// See https://github.com/matrix-org/prosody-mod-auth-matrix-user-verification
2020-09-08 10:44:11 +02:00
if (jitsiAuth === JITSI_OPENIDTOKEN_JWT_AUTH) {
// Request credentials, give callback to continue when received
2020-09-24 21:25:59 +02:00
openIdToken = await widgetApi.requestOpenIDConnectToken();
logger.log("Got OpenID Connect token");
}
widgetApi.on(`action:${ElementWidgetActions.JoinCall}`,
(ev: CustomEvent<IWidgetApiRequest>) => {
joinConference();
ack(ev);
},
);
widgetApi.on(`action:${ElementWidgetActions.HangupCall}`,
2020-10-01 04:51:31 +02:00
(ev: CustomEvent<IWidgetApiRequest>) => {
meetApi?.executeCommand('hangup');
ack(ev);
},
);
widgetApi.on(`action:${ElementWidgetActions.MuteAudio}`,
async (ev: CustomEvent<IWidgetApiRequest>) => {
ack(ev);
if (meetApi && !await meetApi.isAudioMuted()) {
meetApi.executeCommand('toggleAudio');
}
},
);
widgetApi.on(`action:${ElementWidgetActions.UnmuteAudio}`,
async (ev: CustomEvent<IWidgetApiRequest>) => {
ack(ev);
if (meetApi && await meetApi.isAudioMuted()) {
meetApi.executeCommand('toggleAudio');
}
},
);
widgetApi.on(`action:${ElementWidgetActions.MuteVideo}`,
async (ev: CustomEvent<IWidgetApiRequest>) => {
ack(ev);
if (meetApi && !await meetApi.isVideoMuted()) {
meetApi.executeCommand('toggleVideo');
}
},
);
widgetApi.on(`action:${ElementWidgetActions.UnmuteVideo}`,
async (ev: CustomEvent<IWidgetApiRequest>) => {
ack(ev);
if (meetApi && await meetApi.isVideoMuted()) {
meetApi.executeCommand('toggleVideo');
}
2020-10-01 04:51:31 +02:00
},
);
widgetApi.on(`action:${ElementWidgetActions.StartLiveStream}`,
(ev: CustomEvent<IWidgetApiRequest>) => {
if (meetApi) {
meetApi.executeCommand('startRecording', {
mode: 'stream',
// this looks like it should be rtmpStreamKey but we may be on too old
// a version of jitsi meet
//rtmpStreamKey: ev.detail.data.rtmpStreamKey,
youtubeStreamKey: ev.detail.data.rtmpStreamKey,
});
ack(ev);
} else {
2021-06-30 14:28:31 +02:00
widgetApi.transport.reply(ev.detail, { error: { message: "Conference not joined" } });
}
},
);
}
2020-10-01 17:59:13 +02:00
// Now that everything should be set up, skip to the Jitsi splash screen if needed
if (skipOurWelcomeScreen) {
skipToJitsiSplashScreen();
}
2020-10-01 17:59:13 +02:00
enableJoinButton(); // always enable the button
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
} catch (e) {
logger.error("Error setting up Jitsi widget", e);
document.getElementById("widgetActionContainer").innerText = "Failed to load Jitsi widget";
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
}
})();
function enableJoinButton() {
document.getElementById("joinButton").onclick = () => joinConference();
}
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
function switchVisibleContainers() {
inConference = !inConference;
// Our welcome screen is managed by other code, so just don't switch to it ever
// if we're not supposed to.
if (!skipOurWelcomeScreen) {
toggleConferenceVisibility(inConference);
}
}
function toggleConferenceVisibility(inConference: boolean) {
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
document.getElementById("jitsiContainer").style.visibility = inConference ? 'unset' : 'hidden';
document.getElementById("joinButtonContainer").style.visibility = inConference ? 'hidden' : 'unset';
}
function skipToJitsiSplashScreen() {
// really just a function alias for self-documenting code
joinConference();
}
/**
* Create a JWT token fot jitsi openidtoken-jwt auth
*
* See https://github.com/matrix-org/prosody-mod-auth-matrix-user-verification
*/
function createJWTToken() {
// Header
2021-06-30 14:28:31 +02:00
const header = { alg: 'HS256', typ: 'JWT' };
// Payload
const payload = {
2020-09-07 18:23:36 +02:00
// As per Jitsi token auth, `iss` needs to be set to something agreed between
// JWT generating side and Prosody config. Since we have no configuration for
// the widgets, we can't set one anywhere. Using the Jitsi domain here probably makes sense.
iss: jitsiDomain,
sub: jitsiDomain,
aud: `https://${jitsiDomain}`,
room: "*",
context: {
matrix: {
2020-09-24 21:25:59 +02:00
token: openIdToken.access_token,
room_id: roomId,
server_name: openIdToken.matrix_server_name,
},
user: {
avatar: avatarUrl,
name: displayName,
},
},
};
// Sign JWT
// The secret string here is irrelevant, we're only using the JWT
// to transport data to Prosody in the Jitsi stack.
return KJUR.jws.JWS.sign(
'HS256',
JSON.stringify(header),
JSON.stringify(payload),
'notused',
);
}
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
function joinConference() { // event handler bound in HTML
let jwt;
if (jitsiAuth === JITSI_OPENIDTOKEN_JWT_AUTH) {
2020-10-01 04:51:31 +02:00
if (!openIdToken?.access_token) { // eslint-disable-line camelcase
// We've failing to get a token, don't try to init conference
logger.warn('Expected to have an OpenID credential, cannot initialize widget.');
document.getElementById("widgetActionContainer").innerText = "Failed to load Jitsi widget";
return;
}
jwt = createJWTToken();
}
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
switchVisibleContainers();
logger.warn(
"[Jitsi Widget] The next few errors about failing to parse URL parameters are fine if " +
"they mention 'external_api' or 'jitsi' in the stack. They're just Jitsi Meet trying to parse " +
"our fragment values and not recognizing the options.",
);
const options = {
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
width: "100%",
height: "100%",
parentNode: document.querySelector("#jitsiContainer"),
roomName: conferenceId,
interfaceConfigOverwrite: {
SHOW_JITSI_WATERMARK: false,
SHOW_WATERMARK_FOR_GUESTS: false,
MAIN_TOOLBAR_BUTTONS: [],
VIDEO_LAYOUT_FIT: "height",
},
configOverwrite: {
startAudioOnly,
} as any,
jwt: jwt,
};
// Video channel widgets need some more tailored config options
if (isVideoChannel) {
// Ensure that we start on Jitsi Meet's native prejoin screen, for
// deployments that skip straight to the conference by default
options.configOverwrite.prejoinConfig = { enabled: true };
// Use a simplified set of toolbar buttons
options.configOverwrite.toolbarButtons = [
"microphone", "camera", "desktop", "tileview", "hangup",
];
// Hide all top bar elements
options.configOverwrite.conferenceInfo = { autoHide: [] };
}
meetApi = new JitsiMeetExternalAPI(jitsiDomain, options);
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
if (displayName) meetApi.executeCommand("displayName", displayName);
if (avatarUrl) meetApi.executeCommand("avatarUrl", avatarUrl);
if (userId) meetApi.executeCommand("email", userId);
if (roomName) meetApi.executeCommand("subject", roomName);
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
// fires once when user joins the conference
// (regardless of video on or off)
meetApi.on("videoConferenceJoined", () => {
if (widgetApi) {
// ignored promise because we don't care if it works
// noinspection JSIgnoredPromiseFromCall
widgetApi.setAlwaysOnScreen(true);
widgetApi.transport.send(ElementWidgetActions.JoinCall, {});
}
// Video rooms should start in tile mode
if (isVideoChannel) meetApi.executeCommand("setTileView", true);
});
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
meetApi.on("readyToClose", () => {
switchVisibleContainers();
2020-09-08 11:52:17 +02:00
if (widgetApi) {
// We send the hangup event before setAlwaysOnScreen, because the latter
// can cause the receiving side to instantly stop listening.
2020-09-08 11:52:17 +02:00
// ignored promise because we don't care if it works
// noinspection JSIgnoredPromiseFromCall
widgetApi.transport.send(ElementWidgetActions.HangupCall, {}).then(() =>
widgetApi.setAlwaysOnScreen(false),
);
2020-09-08 11:52:17 +02:00
}
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
document.getElementById("jitsiContainer").innerHTML = "";
meetApi = null;
if (skipOurWelcomeScreen) {
skipToJitsiSplashScreen();
}
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
});
meetApi.on("audioMuteStatusChanged", ({ muted }) => {
const action = muted ? ElementWidgetActions.MuteAudio : ElementWidgetActions.UnmuteAudio;
widgetApi.transport.send(action, {});
});
meetApi.on("videoMuteStatusChanged", ({ muted }) => {
const action = muted ? ElementWidgetActions.MuteVideo : ElementWidgetActions.UnmuteVideo;
widgetApi.transport.send(action, {});
});
["videoConferenceJoined", "participantJoined", "participantLeft"].forEach(event => {
meetApi.on(event, () => {
widgetApi?.transport.send(ElementWidgetActions.CallParticipants, {
participants: meetApi.getParticipantsInfo(),
});
});
});
Use a local widget wrapper for Jitsi calls Effectively fixes https://github.com/vector-im/riot-web/issues/11074 Effectively fixes https://github.com/vector-im/riot-web/issues/7112 Fixes https://github.com/vector-im/riot-web/issues/6930 Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933) Fixes https://github.com/vector-im/riot-web/issues/5048 Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json. This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event. Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires. A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
2020-03-18 22:47:56 +01:00
}