Added optional setting http_proxy to push_image #117
Conversation
This will allow the user to set up an external reverse proxy to have the HA instance operate on HTTPS and push_image use that reverse proxy to avoid using HTTPS traffic processing on the plate.
|
Naming this "http_proxy" is misleading, what you are doing is defining the HA as another hostname |
So, maybe |
|
Why don't you move the SSL to the reverse proxy ? and leave the internal HA without SSL ? (that's actual the most common approach) |
|
It is not misleading, no more as the proxy settings in a Linux shell or in a web browser. It is a designated address you divert the request to to proxy it to a different protocol. I have my HA instance reachable from the web and everywhere in the app, special port and https only, to make sure everything works I use this address locally and externally. The only way to do it secure without using the cloud services from nabu casa. |
|
proxy settings in a Linux shell or browser are used by the client, your OpenHASP plate is the client... not HA (this component is the server) - that is why naming it http_proxy is misleading. If you run a local reverse proxy, the proper way is to move SSL termination to the reverse proxy and offload SSL from HA. This way your internal devices can access HA without SSL while external access uses SSL https://www.home-assistant.io/integrations/http/#reverse-proxies |
This is not entirely accurate, from my viewpoint: The integration is sending the plate an image configuration (width, height, url and a command to start loading that image). Which then gets used by the plate as cliënt to execute the desired action. As such, what you do with the HA integration in the automation is configuring the client to use a proxy. Just like you configure it to load specified image. The reverse proxy in this case is on the local network, nobody and nothing will be able to use it from the outside. I think the solution I have set up is generally more secure then to use a proxy to offload ssl traffic for the outside world. The way I did it, every connection to HA is secured. The proxy is configured to allow only access to the plates. Nothing else can use it. |
|
Is this still active? |
|
I would definitely prefer to have this in a next release, yes.
It's just an alternative access for https hosted images...
Op 12 mei 2024 14:54, om 14:54, fvanroie ***@***.***> schreef:
…Is this still active?
--
Reply to this email directly or view it on GitHub:
#117 (comment)
You are receiving this because you authored the thread.
Message ID:
***@***.***>
|
|
It required no modifications for the merge with the release version. |
as a result, automatic updating by the component throws an error and does not work.
Co-authored-by: Diogo Gomes <[email protected]>
The thing is though... it is not an external URL at all. It is meant to be used within the secured environment. With HA running with a https connection secured with a certificate, it will no longer listen on HTTP. That is why the protocol proxy is needed to allow HTTP access to an otherwise HTTPS secured location of an image. This is required to allow the plate to load a dynamic image source from a different HA component (in my case, it loads the image of the doorbell camera). We went over this... I thought I was clear enough in my explanation before. |
I never said I agree :) but I leave to @fvanroie to make the final call |
This will allow the user to set up an external reverse proxy to have the HA instance operate on HTTPS and push_image use that reverse proxy to avoid using HTTPS traffic processing on the plate.
Besides now working around a bug in the libraries that kills SSL traffic on the plates, it will also allow the plate not to deal with SSL encrypted connections at all (even when it is working again) to save processing power.