tldr; The idea is for a server to host javascript that connects to the connected-device's socketServer.
MyDevice's Browser > http://myserver.local > socket.io().connect('http://myDeviceIp:5000');
How best to achieve this and are there any safety implications?
elaborated;
I have a server at 192.168.0.2
- :8080 - browser client (engine control & view)
- :5000 - socketServer (an engine communication channel)
I have 5 Raspberry Pi's at 192.168.0.[3-7]
- :8081 - browser client (remote engine control & view)
- :5001 - socketServer (a hardware communication channel)
The Pi boots into chromium @ http://localhost:8081 instanced from serve --port=8081 $APP_PATH/build/index.js.
But this same client-interface doesn't need build and run on each of 5 devices. So, I want to, instead, change that to server-hosted, a la: http://192.168.0.2:8080/PiClientView. This View.vue would socket.io().connect("192.168.0.3:5001") //.3-7:5001 to perform the same actions it is currently on the self-hosted client.
I have tested this successfully with default values plus adding, e.g., cors:{origin:["http://192.168.0.2:8081"]}-- which works, I believe, as the origin of my content is the server @ 192.168.0.2, but can you affirm that declaration?
- 1.) How can I change the origin to, effectively,
http://192.168.0.***:8081? B.) Are there security pitfalls with this approach? - 2.) Or, would the best solution be to use certificates, a custom header, or authentication?
- 3.) If this is viable/safely achievable, I have an active participant-device that has spotty wifi (but the initial connection is solid). With Chromium's caching, I'm hoping Chromium can fetch it (
http://192.168.0.2/PiParticipantView) and forget it. The View would connects to the local socketServer to receive all the live-updates via MQTT, RF, and hardware-alerting UART would flow between that localDevice socket connection. Are there any shortcomings of this idea?
Thank you so much for your time!
