Skip to content

Web-client browser access

The Canvus web-client is a browser-based way to join a canvas without installing the desktop Canvus client. It is aimed at two audiences, so this page is split accordingly:

  • Sections 1--5 are written for end users --- guests and internal collaborators who open a canvas in a browser.
  • Section 6 is written for operators --- administrators who deploy and maintain the server that hosts the web-client.
  • Section 7 covers troubleshooting for both audiences.

Note

Screenshots for this page are not yet captured. Placeholders in the form ![](_static/screenshots/<name>.png) mark where visuals will be added in a follow-up.

1. Overview

The web-client lets someone open and collaborate on a Canvus canvas entirely in a browser. No installer, no desktop client, no admin rights needed on the viewer's device --- only a modern browser and the shared link.

Use the web-client when:

  • An external collaborator can't or won't install the Canvus desktop client.
  • A participant is on a device or platform that the desktop client doesn't support.
  • You just need quick, read-or-light-edit access to a canvas.

Important

The web-client is a limited-capability surface. It runs inside the browser sandbox, which restricts access to local hardware, native protocols, and high-bandwidth media pipelines. For the full Canvus experience --- including complete widget authoring, touch-wall workflows, local capture devices, and RDP streams --- use the desktop Canvus client. See the Canvus Client Manual.

2. When to use the web-client vs the desktop client

Choose the web-client for lightweight, browser-only collaboration. Choose the desktop client for full fidelity and production use.

Use the web-client when:

  • A guest needs to view or comment on a canvas from a link --- no install.
  • The viewer is on a platform the desktop client doesn't support.
  • A short, opportunistic collaboration session doesn't justify a deployment.

Use the desktop Canvus client when:

  • You need the full widget set and full editing fidelity.
  • You rely on local hardware --- cameras, capture cards, touch walls, pen input.
  • You need native protocols such as remote desktop (RDP) streams.
  • You need long-session performance with large assets or many video streams.

Specific capabilities that are unavailable or limited in the web-client because of browser platform limits:

  • Local capture devices (webcams, capture cards, audio inputs) cannot be published into a canvas from the browser in the same way the desktop client does.
  • RDP / remote desktop streams are not available in the web-client.
  • High-bandwidth live video is routed through the server's WebRTC media service and, depending on deployment, may be degraded compared to the desktop client.
  • Widget authoring and advanced tools are intentionally narrower than the desktop client's toolset (see Section 5).

Treat the web-client as a complement to the desktop client, not a replacement.

3. How users access the web-client

Users reach the web-client via a share link or a QR code. Both point at the same URL pattern.

Share link pattern:

https://canvus.example.com/open/<canvasId>?share=<token>

Opening this URL in a browser loads the web-client and joins the specified canvas.

QR code:

Inside an open canvas, use the Share dialog to generate a QR code for the same URL. A participant scans the QR code with a phone or tablet camera and is taken straight into the canvas.

Tip

QR codes are useful in rooms with a Canvus display: attendees scan once, join the canvas on their own device, and start contributing without installing anything.

4. Authentication

The web-client supports two ways to identify a participant:

Logged-in users. Users with a Canvus account sign in normally, and the web-client inherits their identity and permissions. Administrators appear as administrators, regular users as regular users.

Share-link guest sessions. A share link (?share=<token>) counts as an authenticated session for the duration of the visit, scoped to the canvas referenced by the link. The guest does not need an account. Their access is bounded by the share token's permissions --- revoking the token ends future access.

Sign-out and session teardown. Signing out explicitly tears down the browser session: the server invalidates the associated private token so the link cannot be silently reused from that browser, and any cached state in the browser tab is cleared. Closing the tab alone is not a full sign-out --- use the Sign out action for a clean teardown on shared devices.

5. Supported widget interactions

The web-client targets the common collaboration cases and deliberately omits desktop-only tooling. Interactions available in the current release:

  • View and pan the canvas. Navigate, zoom, and find content.
  • Pin / unpin widgets. The pin state controls whether input interacts with the widget or moves it --- the same rule as the desktop client.
  • Video widgets. Play, pause, and scrub. Playback state (time, play/pause) is synchronised two-way with other participants, so everyone sees the same frame.
  • PDF widgets. Open and paginate through PDF documents.
  • Live streams. View live video streams routed through the server's media service.
  • Annotations and notes. Add notes and basic annotations within the limits of the browser editor.
  • Radial menu. A touch-friendly radial menu provides quick actions for the current selection and for creating common widget types, including folder submenus.
  • Create and upload content. Drop supported files onto the canvas to add them as widgets. The title bar hamburger menu (≡) also provides Upload entries for images, videos, and PDFs — useful when drag-and-drop is impractical on a tablet or touch device. New widgets are created at a sensible default size.

What is not available in the web-client (non-exhaustive):

  • Local camera / capture device publishing.
  • RDP remote-desktop streams.
  • Desktop-only widget authoring flows and advanced configuration panels.
  • Administrative dashboards --- these remain in the server's management console. See Access control for user and permission management.

Note

Feature coverage expands release-to-release. If a widget type or action is missing that you need today, use the desktop client for that session.

6. Operator-side requirements

This section is for server operators. The web-client is served by the Canvus server container and does not need a separate install step, but there are a few things to verify.

Web-proxy process. The container runs an internal web-proxy alongside the server binary. It listens on port 5805 inside the container and forwards browser traffic --- SPA routes (/open/:canvasId), legacy dashboard routes (/, /login, /static/*), and the real-time WebSocket --- to the right backend. Operators normally don't touch this; port 5805 is internal to the container.

Session secret. The web-client uses signed browser sessions. The server expects a stable SESSION_SECRET to be set. Leave it unset in production and sessions will be invalidated on every restart. See Configuration file for the full list of environment variables and INI settings.

External URL. For share links to be correct, the server's external URL must be set. This is the same CANVUS_EXTERNAL_URL / system/external-url value used by the desktop client. See Configuration file.

Ports and TLS. The web-client is served on the same HTTPS port as the rest of the Canvus server (443 by default). External browsers require HTTPS, so deploy a CA-signed certificate if you expect access from outside your network. See Install on Linux for certificate handling.

WebRTC media service. Live video and audio routing is handled by the canvus-media service (mediasoup SFU). If you have disabled or isolated this service, the web-client's video widgets and streams will not work even though the rest of the interface loads. Keep canvus-media reachable from the combined container.

Tip

There is no separate "enable web-client" switch. If the Canvus server container is running with the standard compose file and a valid external URL, the web-client is already available at https://<external-url>/open/<canvasId>.

7. Troubleshooting

Page loads but nothing syncs / widgets never update. The real-time WebSocket isn't connecting. Check that:

  • The browser can reach the server over HTTPS on the configured port.
  • Any reverse proxy between the client and the server passes through the WebSocket upgrade (e.g. for nginx, proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";).
  • The canvas ID in the URL is valid and the share token (if present) has not been revoked.

The client only considers itself joined once it successfully sends {action:'join', canvasId, token} over the WebSocket. If that handshake fails, nothing else will work.

"This canvas isn't available" after opening a share link. Either the token has been revoked, the canvas has been deleted, or the link's external URL no longer matches the server's configured external URL. Regenerate the share link from the canvas.

Video widgets show a placeholder but never play. The WebRTC media service is unreachable. Verify the canvus-media container is running and reachable from the combined container. See media-service/ in the deployment for the service definition.

First-time canvas view opens at an odd zoom / offset. The web-client picks an initial viewport on first open. If users report consistently odd framing, confirm the canvas actually has content in the default region --- an empty canvas will look mis-framed because there is nothing to frame.

Signed-in user is missing admin controls they expect. The web-client refreshes the admin flag from the server on each mount. If permissions were just changed, the user should sign out and back in to pick up the new admin state.

Self-signed certificate warnings on mobile / guest devices. Browser warnings for self-signed certificates are especially intrusive on mobile. For any deployment where external participants will use the web-client, use a CA-signed certificate. See Install on Linux.