Socket port not accessible

I have BrowserSync running in a docker container. Docker maps a random external port to the exposed internal port.

For BrowserSync, this means that the websocket cannot be reached when using the UI. The script used by the UI generates a URL which points at port setting, but the script is being run in a browser outside of the container context.

Example: port 3000 is mapped to 49300 and port 3001 (UI) is mapped to 49301. I visit http://site.dev:49301/ in my browser, the UI page loads. The UI scripts tries to connect to site.dev:3000, which fails.

I’m not really sure how to go about fixing this, as by design, the software running inside a container doesn’t know which port the host has exposed.

[ajacques]

As far as the internal/external port issue, I’ve actually just started seeing this issue after upgrading to the latest version of browsersync. Everything used to work correctly since Browsersync would use the location hostname + port from the browser to create the socket.io path, but now after b2fa3372b806499bf4cd4b978273b740f11fa87d it seems now will use #{location.hostname}:#{port} which isn’t correct in my case. I use NGINX in another docker container to proxy to the Browsersync docker container so the ports that Browsersync aren’t going to be the external one.

Basically, if Browsersync reverts back to using location.host instead of location.hostname I think it should work.

[hanoii]

Although a very old issue I spent a considerable amount of time trying to see the issue and trying potential fixes.

I think I narrowed it down to different commits around work done on #625.

• cf8f9944192545c28c4eeaddd9a8238753272289
• df5c8efdfefaa6863a0083dc0386f53870fd86a0
• 29dfd0a17d5d9c28656c2ea946c48057f955a56d

And probably other related ones.

I believe that when the issue above was done something was not properly thought and some other things were wrongly replaced. First when you set a proxy browser-sync is setting it to “snippet” mode and I believe that’s wrong.

Also, you can set proxy with:

{
target: PROXY_URL
ws: true
}

Which apparently is intended to also proxy the webservice, but then on some other places it feels as the same setting is used in the opposite way.

While I think I could submit a PR I am also not sure if I will cover or be able to test all use cases (like the one on #625) and there seems to be little activity in terms of PRs in the module, so I tried to come up with a workaround.

While probably not great (still neat and useful) this is what I did and it does work.

// The following will overwite the default clinet:script plugin.
// The main issue of this is so that our browsersync works properly on both
// lando and non-lando environments. This is a hacky workaround of different
// issues with BS.
// @see https://github.com/BrowserSync/browser-sync/issues/505
// @see https://github.com/BrowserSync/browser-sync/issues/625
const bscCustom = {
  'plugin:name': 'client:script',
  ...bsc,
  plugin: function initCustom(options, requestBody, type) {
    for (i in requestBody) {
      if (typeof requestBody[i] === 'function') {
        requestBody[i] = (function (fn) {
          var wrappedFn = function() {
            var args = [...arguments].splice(0);
            var output = fn(args);
            return output.replace("___browserSync___.socketUrl = 'http://' + location.hostname + ':3000/browser-sync'", "___browserSync___.socketUrl = 'http://' + location.host + '/browser-sync'");
          }
          return wrappedFn;
        })(requestBody[i]);
      }
    }
    return bsc.plugin(options, requestBody, type);
  }
};

let bs_options = {
  plugins: [bscCustom],
  proxy: {
    target: process.env.MIX_BS_PROXY,
    proxyRes: [
      function(proxyRes, req, res) {
        const proxy_host = proxyRes.req.getHeader('host');
        const destination_host = req.headers['host'];

        // This is to allow our site to work for forms (POSTs).
        for (i in proxyRes.headers) {
          if (Array.isArray(proxyRes.headers[i])) {
            for (j in proxyRes.headers[i]) {
              proxyRes.headers[i][j] = proxyRes.headers[i][j].replace(proxy_host, destination_host);
            }
          }
          else {
            proxyRes.headers[i] = proxyRes.headers[i].replace(proxy_host, destination_host);
          }
        }
      }
    ]
  },
  files: ['assets/js/**/*.js', 'assets/css/**/*.css'],
};

I am setting the local client javascript back to what it was back then like what’s mentioned above.

The proxyRes function might not be needed but I am also documenting it and it’s an useful way of allowing POSTs (forms) to work.

It’s possible that by doing this the intended fix for #625 is lost, so if you have other WS going through the proxy, this might not be the best way of doing it or you might need to do something further.