Greenlight: "You will automatically join when the meeting starts." never moves the user to the meeting when it starts

[davidpesce]

Environment:

• Greenlight 2.5.3
• Scalelite v1.0
• BBB 2.2.3 (x3)

Scenario:
Anonymous user clicks the meeting link before the moderator gets there. They type in their name (press enter) and receive the message, "The meeting hasn't started yet. You will automatically join when the meeting starts." Even after the moderator starts the meeting, the user is never forwarded to the meeting room.

The user's console will show:

WebSocket connection to 'wss://URL/b/cable' failed: Error during WebSocket handshake: Unexpected response code: 404

If the user refreshes the page, it brings them into the meeting.

[farhatahmad]

Hi @davidpesce

Can you consistently reproduce this? Sometimes ActionCable fails, which leads to the user never joining unless they refresh. That being said, there are definitely improvements that we can make on our end to make it more reliable.

You might also want try setting CABLE_ADAPTER=postgresql in your .env file to see if it makes a difference

[davidpesce]

Yeah, it seems to happen every time I try it.

Will try that setting in the .env. Thank you!

[davidpesce]

Bummer. It didn't fix the issue. I should mention that I've tried this on Chrome (latest) only.

[glu000]

I have the same problem but ONLY if Greenlight ist installed on a different server than BBB. If Greenlight and BBB is on the same server it works perfectly fine. Any ideas how to debug this issue?

I have tried it on Chrome, FF, Safari (Mac) and on iPad - same behavior on all browsers

[davidpesce]

@glu000 thats a good point to make! My greenlight is on its own instance as well. I don’t have any installed on the bbb instance. Maybe that’ll help troubleshoot the issue.

[farhatahmad]

Greenlight does have a section in the nginx to handle the /cable request. Maybe there's something wrong with that? Here's the default settings we include:

location /b/cable {
  proxy_pass          http://127.0.0.1:5000;
  proxy_set_header    Host              $host;
  proxy_set_header    X-Forwarded-For   $proxy_add_x_forwarded_for;
  proxy_set_header    X-Forwarded-Proto $scheme;
  proxy_set_header    Upgrade           $http_upgrade;
  proxy_set_header    Connection        "Upgrade";
  proxy_http_version  1.1;
  proxy_read_timeout  6h;
  proxy_send_timeout  6h;
  client_body_timeout 6h;
  send_timeout        6h;
}

[farhatahmad]

Just realized that since you aren't deployed at /b you can probably just remove the /b from before the /cable and that should work

[davidpesce]

@farhatahmad - I actually left it at /b. I wanted to make sure I didn't mess anything up. I plan on getting it at the root, but not just yet.

I have a redirect at the root to go to /b.

[glu000]

@farhatahmad - Thanks for this hint. This solved my problem

Additionally I have to mention, that I use Apache as proxy in front of Greenlight. I had to enable module wstunnel (a2enmod proxy_wstunnel) and add to the configuration a location for /cable:

<Location /cable>
ProxyPass ws://10.149.200.109/cable
ProxyPassReverse ws://10.149.200.109/cable
</Location>

[davidpesce]

I'm still struggling with this one. Is it because the cable redirect is looking at ws:// vs http://?

[davidpesce]

@farhatahmad - any ideas on this?

My only other thought is that it's because I'm behind a load balancer/proxy.

[farhatahmad]

My guess is something to do with HTTP and HTTPS. I haven't had time to dig deep into it and having it only not work when behind a proxy makes it more difficult to fix

[davidpesce]

@farhatahmad - I finally figured this out! The entry under /cable "proxy_set_header X-Forwarded-Proto $scheme;" shouldn't be included.

Long-story short, the issue lies in the fact that the initial request is HTTP(S) and the /cable should only be handling WebSocket requests. Removing that line makes the requests go right through without a problem.

Do you want me to submit a PR for this?

[farhatahmad]

@davidpesce Ah that would make sense.. Good catch. Sure, please send a PR. I'm curious if this will affect SSL installations not behind a proxy though

[davidpesce]

Resolved via #1577

[rottaran]

Many thanks for the hint about the failed websocket connection in the web console!

I tried the proposed fix in #1577 but it did not work for me. Unfortunately, my nginx config is too different. I hat do change location /b { to location ~ (^/b$|^/b/) { because nginx forwarded URLs like /bullshit to the greenlight location. Normally this is no issue because as long as the location path is a full folder like location /b/ {. But somehow this did not work for me. Maybe somebody knows why?

The problem with nginx is, that regexp matches have higher priority than normal pathes and, thus, /b/cable got also handled by the location ~ (^/b$|^/b/) {. This made my websocket fail.

Finally, changing location /b/cable { to location ~ "^/b/cable$" { fixed the wss connection problem for me.

[riteshmaddala]

@farhatahmad - I finally figured this out! The entry under /cable "proxy_set_header X-Forwarded-Proto $scheme;" shouldn't be included.

Long-story short, the issue lies in the fact that the initial request is HTTP(S) and the /cable should only be handling WebSocket requests. Removing that line makes the requests go right through without a problem.

> Do you want me to submit a PR for this?

@davidpesce @farhatahmad @rottaran

@davidpesce - I tried the method you suggested, but didn't worked for me.

So, I fixed this issue by changing the IP Address for /b/cable - earlier it was pointing to 127.0.0.1 and now I updated it to server's IP.

FYI - GreenLight and BBB, both are installed in single instance.

Thanks,
Ritesh