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

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

I understand that’s possible, but it’s the same problem.

I don’t see how that’s the case.

It means two SSLs instead of one

How is this a problem in 2019? With Let’s Encrypt you pretty much don’t need to do anything.

it means DNS settings

One CNAME is enough, since you are going to handle it in your own server.

it means the app isn’t a URL within routing of my app but a completely separate domain.

Not really if you proxy it from your own domain.

Again, this isn’t something that should be an hard to configure - it’s extremely common.

Agreed. I’m just trying to help you here, while this is solved on our side. This is not a feature that sees much use really so I can’t promise you a speedy solution.

If Jitsi truly can be embedded in my app, it should be just that, not living on a separate domain.

We have different understandings of “embedding”. What we mean by it is that any application can put the iframe as part of their application and customize it. Where the source of the iframe is, is irrelevant, as it should be transparent to the app.

There’s also the issue of accessing things inside the iframe - if things are on the same domain this is easy, if they are not it’s not allowed.

That’s not entirely correct. All you need to do is set the right headers to allow it. meet.jit.si, for example, allows any origin. You could configure your installation to only allow your main domain.

Hey @methodbox did you close this intentionally? AFAIK we haven’t fixed this yet.

I understand that’s possible, but it’s the same problem.

I don’t see how that’s the case.

It means two SSLs instead of one

How is this a problem in 2019? With Let’s Encrypt you pretty much don’t need to do anything.

it means DNS settings

One CNAME is enough, since you are going to handle it in your own server.

it means the app isn’t a URL within routing of my app but a completely separate domain.

Not really if you proxy it from your own domain.

Again, this isn’t something that should be an hard to configure - it’s extremely common.

Agreed. I’m just trying to help you here, while this is solved on our side. This is not a feature that sees much use really so I can’t promise you a speedy solution.

If Jitsi truly can be embedded in my app, it should be just that, not living on a separate domain.

We have different understandings of “embedding”. What we mean by it is that any application can put the iframe as part of their application and customize it. Where the source of the iframe is, is irrelevant, as it should be transparent to the app.

There’s also the issue of accessing things inside the iframe - if things are on the same domain this is easy, if they are not it’s not allowed.

That’s not entirely correct. All you need to do is set the right headers to allow it. meet.jit.si, for example, allows any origin. You could configure your installation to only allow your main domain.

Setting up two domains, subdomain or not complicates a lot of things. Take into account the fact that an app developed in a corporate environment needs to meet certain requirements.

Also take into account that two domains shouldn’t be technically necessary if your app was checking the for its files in the correct relative path (which is the reason I consider this a bug), and/or if the base URL was configurable.

Let’s Encrypt is not a long-term option for SSL in our business environment. For a number of reasons, we must use SSLs from a specific vendor as that is our requirement, this means they are paid SSLs.

That’s not entirely correct. All you need to do is set the right headers to allow it. meet.jit.si, for example, allows any origin. You could configure your installation to only allow your main domain.

As I mentioned, I’m a Sys Admin, and I have a lot of experience with Nginx so I’m aware of a number of security issues caused by improper or insecure configurations - this includes allowing something like cross-domain modification of iframes.

See this:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

Using “sameorigin” it will likely be possible to embed the iframe and also make calls and CSS modifications, but this requires the base domain to be the same; it can’t be from a different subdomain.

The setting you’re referring to is likely the “allow-from uri” which is deprecated and not supported in modern browsers, for good reason.

It seems like rather than admitting there is an actual problem, you’re trying to say my use case doesn’t matter.

It seems if the intention is to allow Jitsi to be embedded in an app and there is no requirement listed to run it on a separate domain, or configurable option to set the base URL, this intention and the actual functionality of Jitsi are at odds.

That’s either a bug or simply something you don’t want to support, but the solution isn’t just “fix your web server”.

Thank you very much for your post. I tried to use some parts of your config, but the jitsi:80 thing in your upstream didn’t work for me. I use the default docker-compose for jitsi (apart from adding the volume for the base.html" and have installed nginx directly on my server. Maybe that’s the problem.

This is getting a little off-topic: But in that case, of course, you have to publish your jitsi-web’s port 80 to port 8000 (at least you are trying to reach it there (i.e. you need a “-p 8000:80” parameter when starting the jitsi-web container or the corresponding in docker-compose.yml) and it looks like the nginx-proxy does not correctly remove the “jitsi” subpath from the url, before giving it to localhost:8000. I suspect that is what the prexy_redirect and proxy_set_header entries might be doing, but I’m not a 100% sure. For me it seems to work with the config I have shown you. Best of luck.

Again, a great example of why you may want to open your own issues (literally everyone else who has posted that isn’t me or from Jitsi) because this isn’t getting watched by Jitsi and this is way outside the scope of the original issue.

Thank you very much for your post. I tried to use some parts of your config, but the jitsi:80 thing in your upstream didn’t work for me. I use the default docker-compose for jitsi (apart from adding the volume for the base.html" and have installed nginx directly on my server. Maybe that’s the problem.

This is getting a little off-topic: But in that case, of course, you have to publish your jitsi-web’s port 80 to port 8000 (at least you are trying to reach it there (i.e. you need a “-p 8000:80” parameter when starting the jitsi-web container or the corresponding in docker-compose.yml) and it looks like the nginx-proxy does not correctly remove the “jitsi” subpath from the url, before giving it to localhost:8000. I suspect that is what the prexy_redirect and proxy_set_header entries might be doing, but I’m not a 100% sure. For me it seems to work with the config I have shown you. Best of luck.

I’ve solved the issue for me. I simply had to adjust the base.html at /usr/share/jitsi-meet/base.html in the docker container

@Mehrtuerer Thank you, your solution looks very promising, but I can’t get it to work. Have you maybe done anything else in order to solve the issue? I verified (with docker exec <webcontainername> cat /usr/share/jitsi-meet/base.html) that my volume is working correctly and I also restarted everything with docker-compose.

I still get this error when checking my-domain.de/jitsi:

Missing https://my-domain.de/jitsi/css/all.css?v=3969

Also if I check it locally on my server, I get the following:

wget localhost:8000/jitsi/css/all.css
HTTP request sent, awaiting response... 404 Not Found

My base.html looks like this: <base href="/jitsi/" />

My nginx config looks as simple as that:

server {
  server_name my-domain.de;
  
  location /jitsi {
     proxy_pass http://localhost:8000;
  }

  location /other {
     proxy_pass http://localhost:8080;
  }
  #ssl stuff ...
}

If you have any hint I’d really appreciate it.

My nginx config looks just slightly more complex, but I can’t really explain what all the proxy_redirect and proxy_header lines are doing:

upstream jitsi {
    server jitsi:80; # Here jitsi is the jitsi-web container's name within the same docker-network as this nginx-proxy is in.
}

server {
    #ssl stuff ...

    location = /jitsi {
        return 302 /jitsi/; # Just make sure the next location rule always matches correctly
    }

    location /jitsi/ {
        proxy_pass http://jitsi/; # Here jitsi is the name of the upstream we configured earlier in the config file
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Host $server_name;
    }
}

Hope that helps.

I’ll take a look at this, I suspect where the problem is.

but it seems a waste to have to spin up a completely separate server just to be able to embed the iframe and also have my app on the web root.

Not sure I understand. You don’t need 2 servers. You could just use a subdomain with a different web root. Then you can proxy a subdirectory in your web root to the subdomain, but at thay point, you might as well use the subdomain directly.

I understand that’s possible, but it’s the same problem. It means two SSLs instead of one, it means DNS settings and it means the app isn’t a URL within routing of my app but a completely separate domain.

Again, this isn’t something that should be an hard to configure - it’s extremely common.

If Jitsi truly can be embedded in my app, it should be just that, not living on a separate domain.

There’s also the issue of accessing things inside the iframe - if things are on the same domain this is easy, if they are not it’s not allowed.