You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 15, 2023. It is now read-only.
our setup is slightly odd (!) in that we are using a dynamic nginx setup with docker, so that when a docker container spins up, it registers a domain with nginx and secures it with https from let's encrypt
so, I spin up my container foo, and run a node process on port 3000. In the background, foo.myapp.io is registered, and nginx listens for a https connection on port 443, and forwards the connection to the foo docker container on port 3000
However, there is a problem in that we can only use standard ports (80 / 443) in order to get round some firewall issues. We get round this by generating another domain wss-foo.myapp.io and mapping that request to the internal port 9485
All's well and good at this point - npm start fires up, and I can indeed access the server
However, the problems start with auto-reload
internally, within the docker container, the brunch process is running http, byt nginx is running https. This means that the auto-reload websocket server starts on plain http, and the injected client code tries to use ws:// which then causes problems with https and an insecure ws call
this can be fixed by adding an extra option to the auto-reload config, and using wss if this option is set
The second problem is slightly harder : the injected client uses the server name that is started (ie foo.myapp.ip, where I actually need it to use wss-foo.myapp.io
I was looking at the code in auto-reload-brunch, and in the vendor folder, there is the auto-reload.js client code. This code is where it uses the server.
I was interested to see this line of code
varar=br['auto-reload']=(br['auto-reload']||{});
does that mean that there is a way of getting some config data from the server to the client ? If so, then I can add another extra option to the config, a wss hostname
So, at the end of a very long issue : the real question is,
Is it possible to get the auto-reload.js client file to use options from the server ?
thanks.
The text was updated successfully, but these errors were encountered:
our setup is slightly odd (!) in that we are using a dynamic nginx setup with docker, so that when a docker container spins up, it registers a domain with nginx and secures it with https from let's encrypt
so, I spin up my container foo, and run a node process on port 3000. In the background, foo.myapp.io is registered, and nginx listens for a https connection on port 443, and forwards the connection to the foo docker container on port 3000
However, there is a problem in that we can only use standard ports (80 / 443) in order to get round some firewall issues. We get round this by generating another domain wss-foo.myapp.io and mapping that request to the internal port 9485
All's well and good at this point - npm start fires up, and I can indeed access the server
However, the problems start with auto-reload
this can be fixed by adding an extra option to the auto-reload config, and using wss if this option is set
I was looking at the code in auto-reload-brunch, and in the vendor folder, there is the auto-reload.js client code. This code is where it uses the server.
I was interested to see this line of code
does that mean that there is a way of getting some config data from the server to the client ? If so, then I can add another extra option to the config, a wss hostname
So, at the end of a very long issue : the real question is,
Is it possible to get the auto-reload.js client file to use options from the server ?
thanks.
The text was updated successfully, but these errors were encountered: