Kurento Room and Nginx Proxy

[Travis James]

Good morning!  I am having an issue with serving Kurento Room behind an Nginx proxy.  Here is the scenario:

• I configure Nginx to act as a reverse proxy on port 80 forwarding requests to an instance of Kurento Room at 8080.  Nginx is configured to accept requests at http://[DNS name] at port 80.
  
• Kurento Room's configuration JSON specifies the app URL as "http://[DNS name]:8080".
• I have the firewall set open at both 8888 and 8080, so requests can come through for Kurento directly AND the same server can work at port 8080 without a proxy.
  

The weird thing is that the system looks like it works, but it doesn't.  Two different users never appear in the same room of the same name.  However, when I navigate to http://[DNS name]:8080, everything works perfectly.

Ideally, I would like to have this all working via SSL through Nginx, with Nginx working as the SSL terminator and load balancer (albeit with ONE server specified).

The behavior indicates that somewhere in Javascript for rooms (not Kurento, since in both cases a session works), the app URL from the room configuration file is used to connect to the Room Server via websockets or HTTP, and, thus, does not have the proper "cookie", header, or "session" state in that call (since the original session is established via proxied request).

How can I configure Kurento Rooms to make a proxied configuration work? 

[Ivan Gracia]

That's a good one. The client connects with the room server via WebSockets, so that's what you'll have to proxy. We actually don't normally proxy connections to the apps, and the times we've done that found that the proxy was yielding unexpected behaviour with WS. For instance, we are normally relying on the onClose event from the WS connection to know if one of the ends is gone. With proxies (in our case, it was a load balancing proxy), you can't do that as the WS is established with the proxy, so the client could disappear and the WS would still be open.

I'll try to have a look at that next week, see if I can provide more info, but I think with nginx you just need to let the Upgrade headers through

location /my-ws-app/ {
    proxy_pass http://localhost:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Ivan Gracia

--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Travis James]

Thanks very much for your response.  However, it turns out that internal code somewhere in the Kurento Rooms implementation still causes the UI to expect to address the 8080 port directly (not something with WebSockets) and that is enough to confuse the application (since currently I have BOTH ports open in the firewall, so a request starts on port 80--or 443--and subsequent requests are made on 8080).

I have not figured out where the 8080 dependency is introduced, but it seems to be there...

Travis

[Ivan Gracia]

Thanks for the info. Can't have a look this week, but I've opened an issue on that so we don't forget. Please let us know if you find that before we do ;-)

Ivan Gracia

[Travis James]

I just wanted to check to see if this has been addressed.  It has become more important, since the new versions of the Chrome browser now require HTTPS in order to succeed with a "getUserMedia" call.  As a result, the Rooms demo no longer works.

[Ivan Gracia]

We haven't had the time to solve this yet, sorry! We'll try and have a look at it this week. The first version that will require HTTPS for all getUserMedia calls is in Canary right now, so we are planning to adapt tutorial in some weeks. In any case, self-signed certificates won't be accepted, so it might very well be that many people will find issues with this.

Ivan Gracia

[Travis James]

I am working on a Node.js version of a room server now that will address this problem, but it will be a week or two before I can finish it.  I was just asking, because for now, in my Docker-based demo, I am using Kurento Room temporarily, and the latest Android builds already have distributed a version of Chrome where this doesn't work anymore (HTTPS required).

I will keep you guys posted on my progress.  

[Ivan Gracia]

Thanks! It coul be something related to the Angular client. We still have the issue open.

Ivan Gracia

[michael...@gmail.com]

I ran into a similar problem trying to get the group tutorial demo to work on a AWS EC2 instance using nginx https and websocket forwarding.  We have a valid ssl cert and the https page would load fine, but opening a secure socket would consistently return a 403 error.  In order to get wss forwarding to work, setAllowedOrigins("*") needs to be called within the registerWebSocketHandlers override.

FWIW, I've created a pull request that updates all tutorials with the registerWebSocketHandlers override and the added setAllowedOrigins("*") call ...

https://github.com/Kurento/kurento-tutorial-java/pull/4

[Ivan Gracia]

Yeah, that's something you have to do with Spring > 4.1.5. We should probably add a note on that in the documentation, instead of setting the allowed origins with the wildcard. Though it's just a tutorial, maybe we shouldn't encourage that practice.

@Micael Would that be OK with you? We'll add a note in the Securing Kurento Apps section... Which I just realised didn't get published in the latest release. Will fix that right away!

Ivan Gracia

[Micael Gallego]

We can add a note in the not-yet-published Securing Kurento Apps section indicating that it is better to change the value in setAllowedOrigins(..) method to further secure your application. But in the sake of simplicity I would't change that value in tutorials code. 

On the other hand... Kurento Room has its own documentation (http://doc-kurento-room.readthedocs.org)

Best...

Micael Gallego
http://about.me/micael.gallego

[Soumya Ranjan Bohidar]

Unfortunately, I witness the same currently. My App hosted on nginx reverse proxy and while connecting to KMS over ws from kurento-client, it consistently logs reconnect to server n 10000 undefined. My KMS is hosted on ws://localhost:8888 with docker image available.

location ^~ /rtc {

    proxy_http_version 1.1;

    proxy_set_header Upgrade $http_upgrade;

    proxy_set_header Connection "upgrade";

    proxy_set_header Host $host;

    proxy_pass http://localhost:3000;

proxy_read_timeout 86400;

proxy_buffers 8 32k;

proxy_buffer_size 64k;

proxy_set_header 'Access-Control-Allow-Origin' '*' always;

}

Any help is appreciated.