Jitsi cannot be run from a subdirectory

This Issue tracker is only for reporting bugs and tracking code related issues.

Before posting, please make sure you check community.jitsi.org to see if the same or similar bugs have already been discussed. General questions, installation help, and feature requests can also be posted to community.jitsi.org.

Description

---

Before closing this and referring to a previous issue, please consider I am a Systems Admin and have been writing JS for 7 years.

I’m VERY familiar with Nginx and how to configure it. The solution is not the web server. It may be Jitsi configuration I’ve overlooked.

It seems impossible to just run Jitsi not as the root application - I don’t mean simply running it from a subdirectory, I mean running it as https://domain.com/jitsi-is-here/ vs. at domain URL root.

A subdomain is not a solution. This unnecessarily complicates using an SSL which is already configured for Jitsi. We should not need a separate server or SSL just for Jitsi.

Current behavior

---

Running Jitsi in a location other than web root results in Jitsi exhibiting behavior that is in contrast with what you (Jitsi devs) have stated here:

https://github.com/jitsi/jitsi-meet/issues/2422

… which is that you simply have to configure the web server.

When I provide the Jitsi Meet files in /api and try to hit my server at https://myserver.com/api, it fails to find files in relative paths - Jitsi fails to find them and update the relative paths.

This is evidenced by following the Nginx logs. Hitting my own app, for example and hitting relative paths in the URL, files load as expected, without issue; I am not rewriting or controlling the URL inside my app because this causes problems - as it appears Jitis is.

Instead of looking for it’s files in the root of the path where Jitsi lives, it’s looking for them at the server root.

If I wanted, for example to run my site on mysite.com/ and run Jitsi at mysite.com/api the result is that Jitsi looks for it’s configuration and other files at mysite.com/ even though it is physically located in /api.

Nginx is configured to provide a path to /api. Its root is configured for /usr/share/mysite. The /api path is alias /usr/share/mysite/api which is the physical location of Jitsi Meet.

Jitsi doesn’t seem to care that it’s index.html loads from mysite.com/api; (it loads broken, but it loads - i.e. the web server is doing it’s job) it still tries to path all of it’s files relative to web root.

This is common configurable behavior (see: every CMS every created, exa. Wordpress, nearly every JVM app every created, see: Graylog, and many, many others) where you can usually set a base or root URL. There doesn’t seem to be a configuration option for this.

However, I see this as a bug not because it can’t be configured but because the behavior seems to ignore its own relative path. This doesn’t make much sense.

If it is configurable, please let me know how, in detail I can configure this and I guess this could be closed.

Expected Behavior

---

I should be able to use a subpath URL to use as Jitsi’s root. Jitsi should not expect to be on the root or it should adapt.

Simply stated, I should be able to put Jitsi anywhere on my server, point the web server to this location and Jitsi should run.

Possible Solution

---

• Stop trying to force the relative path in your application.
• Provide a specific configuration for using an alternate base URL (not web server config but application config).
• Don’t assume your app will be on the web root.

Steps to reproduce

---

Move Jitsi Meet into a subdirectory. Configure Nginx to point to this directory on a non-web root path. Visit that URL and watch Jitsi break.

Environment details

---

Debian Stretch.

[ilfrick]

I’ve been trying, without success, to accomplish this as well for a few days now. Can you reopen the issue @saghul ?

[Omnifarious]

I really need this reopened as well. I want to run a Jitsi server that can only be used by a very select few people. My solution to this is running in at https://domain/<secret>/ but I can’t make this work. This is perfectly secure if I always use a secure channel to transfer the URL to just the people I want to have access, and it avoids annoying authentication hassles.

This other guy wants to do the same thing: https://community.jitsi.org/t/how-to-modify-nginx-setup-in-order-to-use-a-soft-link-to-start-jitsi-meet/22880