Skip to content

CORS Errors when attempting to connect with a self- hosted Jitsi meeting #15749

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

Open
3 of 11 tasks
factor3 opened this issue Mar 10, 2025 · 2 comments
Open
3 of 11 tasks

Comments

@factor3
Copy link

factor3 commented Mar 10, 2025

What happened?

I am attempting to run a Jitsi service from within Docker, which I am accessing through the Nginx Proxy Manager.

The service comes up when I access it, and when I enter a meeting place, it displays the page with the "Start Meeting" button, requests access to my camera and audio, and displays me in its camera view when I allow it access to the camera.

Unfortunately, it does the following when I actually click on the "Start Meeting" button:

  1. It waits for several seconds
  2. It displays a dialog box that says "You have been disconnected"
  3. If I click on the "Rejoin now" button displayed in the dialog box, it redisplays the Join Meeting page
  4. If I don't click on the "Rejoin now" button, it counts down the seconds and redisplays the Join Meeting page

Out of curiosity, I monitored the console to see what was happening when I clicked on the Join Meeting button, and I saw the CORS errors shown below:

Image

Apparently, the client makes several attempts to access /http_bind and having its attempts blocked due to Cross- Origin restrictions, then it gives up, displays the "You have been disconnected" dialog, and then reloads the Join Meeting page.
``
My .env file is duplicated below (with sensitive stuff like my IP address and passwords redacted):

# shellcheck disable=SC2034

################################################################################

################################################################################

# Welcome to the Jitsi Meet Docker setup!

#

# This sample .env file contains some basic options to get you started.

# The full options reference can be found here:

# https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker

################################################################################

################################################################################

#

# Basic configuration options

#

# Directory where all configuration will be stored

CONFIG=~/.jitsi-meet-cfg

# Exposed HTTP port (will redirect to HTTPS port)

HTTP_PORT=9002

# Exposed HTTPS port

HTTPS_PORT=8443

# System time zone

TZ=UTC

# Public URL for the web service (required)

# Keep in mind that if you use a non-standard HTTPS port, it has to appear in the public URL

PUBLIC_URL=https://<My Public URL>:8443

# Media IP addresses to advertise by the JVB

# This setting deprecates DOCKER_HOST_ADDRESS, and supports a comma separated list of IPs

# See the "Running behind NAT or on a LAN environment" section in the Handbook:

# https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker#running-behind-nat-or-on-a-lan-environment

JVB_ADVERTISE_IPS=<The IP address of the Jitsi Server>

#

# Memory limits for Java components

#

#JICOFO_MAX_MEMORY=3072m

#VIDEOBRIDGE_MAX_MEMORY=3072m

#

# JaaS Components (beta)

# https://jaas.8x8.vc/

#

# Enable JaaS Components (hosted Jigasi)

# NOTE: if Let's Encrypt is enabled a JaaS account will be automatically created, using the provided email in LETSENCRYPT_EMAIL

#ENABLE_JAAS_COMPONENTS=0

#

# Let's Encrypt configuration

#

# Enable Let's Encrypt certificate generation

#ENABLE_LETSENCRYPT=1

# Domain for which to generate the certificate

#LETSENCRYPT_DOMAIN=meet.example.com

# E-Mail for receiving important account notifications (mandatory)

#[email protected]

# Use the staging server (for avoiding rate limits while testing)

#LETSENCRYPT_USE_STAGING=1

#

# Etherpad integration (for document sharing)

#

# Set the etherpad-lite URL in the docker local network (uncomment to enable)

#ETHERPAD_URL_BASE=http://etherpad.meet.jitsi:9001

# Set etherpad-lite public URL, including /p/ pad path fragment (uncomment to enable)

#ETHERPAD_PUBLIC_URL=https://etherpad.my.domain/p/

#

# Whiteboard integration

#

# Set the excalidraw-backend URL in the docker local network (uncomment to enable)

#WHITEBOARD_COLLAB_SERVER_URL_BASE=http://whiteboard.meet.jitsi

# Set the excalidraw-backend public URL (uncomment to enable)

#WHITEBOARD_COLLAB_SERVER_PUBLIC_URL=https://whiteboard.meet.my.domain

#

# Basic Jigasi configuration options (needed for SIP gateway support)

#

# SIP URI for incoming / outgoing calls

#[email protected]

# Password for the specified SIP account as a clear text

#JIGASI_SIP_PASSWORD=passw0rd

# SIP server (use the SIP account domain if in doubt)

#JIGASI_SIP_SERVER=sip2sip.info

# SIP server port

#JIGASI_SIP_PORT=5060

# SIP server transport

#JIGASI_SIP_TRANSPORT=UDP

#

# Authentication configuration (see handbook for details)

#

# Enable authentication (will ask for login and password to join the meeting)

#ENABLE_AUTH=1

# Enable guest access (if authentication is enabled, this allows for users to be held in lobby until registered user lets them in)

#ENABLE_GUESTS=1

ENABLE_XMPP_WEBSOCKET=0

# Select authentication type: internal, jwt, ldap or matrix

#AUTH_TYPE=internal

# JWT authentication

#

# Application identifier

#JWT_APP_ID=my_jitsi_app_id

# Application secret known only to your token generator

#JWT_APP_SECRET=my_jitsi_app_secret

# (Optional) Set asap_accepted_issuers as a comma separated list

#JWT_ACCEPTED_ISSUERS=my_web_client,my_app_client

# (Optional) Set asap_accepted_audiences as a comma separated list

#JWT_ACCEPTED_AUDIENCES=my_server1,my_server2

# LDAP authentication (for more information see the Cyrus SASL saslauthd.conf man page)

#

# LDAP url for connection

#LDAP_URL=ldaps://ldap.domain.com/

# LDAP base DN. Can be empty

#LDAP_BASE=DC=example,DC=domain,DC=com

# LDAP user DN. Do not specify this parameter for the anonymous bind

#LDAP_BINDDN=CN=binduser,OU=users,DC=example,DC=domain,DC=com

# LDAP user password. Do not specify this parameter for the anonymous bind

#LDAP_BINDPW=LdapUserPassw0rd

# LDAP filter. Tokens example:

# %1-9 - if the input key is [[email protected]](mailto:[email protected]), then %1 is com, %2 is domain and %3 is mail

# %s - %s is replaced by the complete service string

# %r - %r is replaced by the complete realm string

#LDAP_FILTER=(sAMAccountName=%u)

# LDAP authentication method

#LDAP_AUTH_METHOD=bind

# LDAP version

#LDAP_VERSION=3

# LDAP TLS using

#LDAP_USE_TLS=1

# List of SSL/TLS ciphers to allow

#LDAP_TLS_CIPHERS=SECURE256:SECURE128:!AES-128-CBC:!ARCFOUR-128:!CAMELLIA-128-CBC:!3DES-CBC:!CAMELLIA-128-CBC

# Require and verify server certificate

#LDAP_TLS_CHECK_PEER=1

# Path to CA cert file. Used when server certificate verify is enabled

#LDAP_TLS_CACERT_FILE=/etc/ssl/certs/ca-certificates.crt

# Path to CA certs directory. Used when server certificate verify is enabled

#LDAP_TLS_CACERT_DIR=/etc/ssl/certs

# Wether to use starttls, implies LDAPv3 and requires ldap:// instead of ldaps://

# LDAP_START_TLS=1

#

# Security

#

# Set these to strong passwords to avoid intruders from impersonating a service account

# The service(s) won't start unless these are specified

# Running ./gen-passwords.sh will update .env with strong passwords

# You may skip the Jigasi and Jibri passwords if you are not using those

# DO NOT reuse passwords

#

# XMPP password for Jicofo client connections

JICOFO_AUTH_PASSWORD=***********

# XMPP password for JVB client connections

JVB_AUTH_PASSWORD=************

# XMPP password for Jigasi MUC client connections

JIGASI_XMPP_PASSWORD=************

# XMPP password for Jigasi transcriber client connections

JIGASI_TRANSCRIBER_PASSWORD=************

# XMPP recorder password for Jibri client connections

JIBRI_RECORDER_PASSWORD=************

# XMPP password for Jibri client connections

JIBRI_XMPP_PASSWORD=************

#

# Docker Compose options

#

# Container restart policy

#RESTART_POLICY=unless-stopped

# Jitsi image version (useful for local development)

#JITSI_IMAGE_VERSION=latest

As stated, I am using Nginx Proxy Manager (NPM) to reverse proxy my Jitsi server. My setup for NPM is provided below:

Image

Image

Platform

  • Chrome (or Chromium based)
  • Firefox
  • Safari
  • Other desktop browser
  • Android browser
  • iOS browser
  • Electron app
  • Android mobile app
  • iOS mobile app
  • Custom app using a mobile SDK

Browser / app / sdk version

All the latest browsers identified above, including the Brave browser.

Relevant log output

I don't know how to get the Jitsi meet logs from the docker container to post here. I have monitored the log output using "docker compose logs", and there are no log messages that occur when I click on the "Start Meeting" button. This makes sense, though, because the CORS violations are preventing the client from connecting.

Reproducibility

  • The problem is reproducible on meet.jit.si

More details?

No response

@barathraj048
Copy link

barathraj048 commented Mar 15, 2025

The possible cause of the CORS errors in your self-hosted Jitsi Meet instance is that the BOSH endpoint is configured on a different port than the frontend, causing the browser to block the cross-origin requests.

Solution 1: Frontend and BOSH on the Same Origin

What it does: Puts the frontend and the BOSH endpoint (/http-bind) under the same domain and port, eliminating CORS problems altogether.
How to do it:
Update the BOSH URL in your Jitsi configuration (e.g., config.js) to a relative path such as /http-bind.
Configure your Nginx Proxy Manager to proxy all traffic, including /http-bind, to the Jitsi web container.
Restart your Docker containers to implement the changes.
Why it works: Having everything on the same origin avoids triggering CORS restrictions in the browser.

Solution 2: Enable CORS on the Server

What it does: Enables cross-origin requests if the BOSH endpoint needs to be accessed via a different port (e.g., 8443).
How to do it:
Modify the Prosody configuration file (prosody.cfg.lua) by setting cross_domain_bosh = true or by defining the frontend's domain.
Mount the new configuration into the prosody container via docker-compose.yml.
Restart the Prosody container to implement the changes.
Make sure Nginx Proxy Manager passes CORS headers properly, including custom settings where needed.
Why it works: This specifically allows the frontend to request another origin, meeting the browser's security requirements.

try this and update if anything goes off

@arnavsharma990
Copy link

i think i can solve it effectively , please do assign me with it @barathraj048

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

No branches or pull requests

3 participants