Comment by noduerme | Hacker News Reader

Comment by noduerme | Hacker News Reader

I have just been going through a HELL of a time building a web-based app ("PWA" in progressive lingo) that needs to auto-discover certain devices on the user's LAN. This is a rebuild of an existing AIR-based app that's been in use in a corporate setting for 10 years and needs to be replaced because "death of flash". The AIR app I wrote back then handled discovering the local devices fantastically well. The problem now? Mixed-origin blockades. I can't get into all those devices and routers in each location to set up local DNS servers and maintain certificates. So the connection from the ultimate app to the local node has to be unencrypted. But this means the only answer to a web-based discovery app is to have it be served over HTTP as well.

Interesting thing google missed when trying to prevent people from doing this exact thing with PWAs: If you have a valid manifest and service worker, Chrome won't run the service worker if it's not served over SSL, but it WILL include the app name and icons and let you save it to the home screen on Android; it will even cache a good deal of what you intended.

For auto-discovery, I used a fuckton of hidden iframes loading asynchronously and waiting for any window.postMessage that matches what I want from a local device.

Seriously, Google has made my life fucking miserable as a solo dev. They don't want anyone to be able to write an IoT app without going through them.

Actually I'm kind of glad it's difficult to do those sort of things in Chrome.

There are fantastic reasons why it should not be allowed on random local devices, unless the local device is configured with some sort of authentication... but the problem now is that total ban on accessing local devices from a secure web app is a serious choke point for anyone trying to develop something to control appliances outside the walled garden.

Fascinating discussion here with a Plex dev expressing similar frustrations with the general direction of these context barriers... which in their case affects millions of users and threatens to pull down their entire platform. Their solution currently is bizarre; they actually have to hijack DNS resolution and issue SSL certs on the fly for each of their users' servers to allow their web app to connect to a local node. Not possible in my smaller corporate sphere.

https://github.com/WICG/private-network-access/issues/23

Dumb question. Why not just get a free subdomain and get a letsencrypt certificate for each device?

https://community.letsencrypt.org/t/dns-providers-who-easily...

Valid question. The devices are in shops all over the country and should be able to run autonomously. I don't want to get into the business of remotely managing those machines, setting up certificates and DNS on each one, especially since I have no control over the routers in the shops. Supporting the app is hairy enough without trying to do tech support for each shop's network issues.

We're a industrial-control company whose traditional UI has been standard win32 applications - we've slowing converting our stack over to a web interface but as our UI needs to talk to lots of local devices, we've hit the problems you described.

Our solution has been to basically mandate that the user install either a small embedded device (ie. RPI or equiv) or manually launch a container. These essentially just serve as a local websocket / api router so Chrome connects to some local "device/container" and then that connects to all the local devices.

Although this is a logistical hurdle, its actually simplified other aspects of development since now this device/container has a bit of intelligence and can act as real middleware to simplify what the UI needs to contemplate. Basically MVC-style development using hardware bits as Controller.

That's cool. I guess our problem could be described as allowing non-technical users to control the in-shop devices from an app on their phone (both android and iOS) without knowing the local IP at all. Like, how do we determine the shifting dynamic IP of our in local routing system from an app served from the cloud ...and the answer unfortunately is we can't. We have to serve the app locally in each facility.

Thats something similar to what we are doing...

* Local RPI / Container connects to message queue in cloud * Web User inputs request to Web UI (cloud) * Local RPI / Container retrieves request via queue and access final device * Reports status back to queue which is then reported by Web UI

Basically the local device is your router using whatever message queue you want.

React Native and (maybe) Electron are nice if you need access to real networking but want to write webtech, and can afford to impose somewhat on your end user. Browsers (very much rightly, IMO) lack a lot of handy stuff for local device discovery, including, notably, all of UDP.

Reply on news.ycombinator.com