search

dresden-elektronik / deconz-rest-plugin-v2

deCONZ REST-API version 2 development repository.
BSD 3-Clause "New" or "Revised" License
17 stars 0 forks source link

Alternative protocols for the REST API (HTTPS, WebTransport) #20

Open Thomas-Vos opened 1 month ago

Thomas-Vos commented 1 month ago

I am experimenting with a web app but unfortunately HTTP does not work from a HTTPS web app. So something else needs to be added. Also remote access over the Internet would be a nice addition.

Some useful information here: https://developer.chrome.com/blog/private-network-access-update

Alternative options:

HTTPS

Not that great for web-apps, but nice for native Android/iOS apps. Can still be used with web-apps as a fallback but not ideal due to self-signed certificates.

WebTransport

Seems like a great solution for web-apps, but would require extra work in deCONZ. (HTTP/3)

From the Chrome blog: image

A comment from @manup (07/06/2024):

Good find, this can indeed be a solution but it comes with some challenges (if I understand the tech right).

  • deCONZ needs HTTP/3 + Quick support for this (not easy but doable)
  • Normal REST requests don't work over it, it's more like a WebSocket connection. So we'd need to tunnel the REST API through such a connection. Personally I think that might be a nice addition also for WebSocket connections. But the REST client code needs to be adapted to such a change, and depending on how abstracted the REST client code is this may be quite a task.

I've started to work on the new TCP/SSL code (also to get rid of Qt here over time) so the normal HTTPS support will come first – which should be a good option for all non browser clients. No ETA yet until I figure out what parts need to be refactored.

I'd suggest for the REST API through WebSocket/WebTransport tunneling is also a good point for the next meeting. WebRTC DataChannels might also be an option here with wider browser support, but my knowledge here is yet to limited to say for sure. Oh, one more interesting aspect of WebTransports is, that the client needs to know the SHA-256 hash of the current certificate. Currently this could be transferred via a mixed content hidden in an image, but I guess that's only supported for a while until this gets removed too from browsers. And from there on this would need to be signaled over a public channel like the discovery server, doable but not a good dependency. The certificates themself are required to be rotated after 2 weeks at latest.

Tor

...