Emulated Hue: Limited to RFC1918 IPv4 addresses #30701
Comments
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
Nothing has changed. Public IPs are still not allowed (in homeassistant/components/emulated_hue/hue_api.py). |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
Nothing has changed. Public IPs are still not allowed (in homeassistant/components/emulated_hue/hue_api.py). |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
Nothing has changed. Public IPs are still not allowed (in homeassistant/components/emulated_hue/hue_api.py). |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
Nothing has changed. Public IPs are still not allowed (in homeassistant/components/emulated_hue/hue_api.py). |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
Nothing has changed. Public IPs are still not allowed (in homeassistant/components/emulated_hue/hue_api.py). |
|
I would like to keep this topic/issue open. I have the same problem using a local network with different ip schema. The thing is, I want to use this schema on my own-private-network, so I don't know why this have to be enforced via hard coding it instead of using a config parameter to allow non RFC1918 addresses. Also I don't want to edit the py to remove any reference to this enforcing jail, because with new updates, all changes will be removed as well. This could not be turning into a cat-mouse game. |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
Well it seems that maybe changing the code is the only way and keeping doing it every update... |
|
Yes, that's right. That's what I do :-/ |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
This was blocked intentionally in #17248 |
|
Nothing has changed. Limiting access to RFC1918 addresses is still a very bad idea. |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
Nothing has changed. Limiting access to RFC1918 addresses is still a very bad idea. |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
Nothing has changed. Limiting access to RFC1918 addresses is still a very bad idea. |
|
+1 that thinking your app is secure because you're requiring RFC1918 is just irresponsible and immature. If it's desired to be a flag, that's fine but address space is address space. I'd encourage the fix for this be merged. |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
Nothing has changed. Limiting access to RFC1918 addresses is still a very bad idea. |
|
It would be great to be able to use the service in my LAN. |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
Would the current maintainers be interested in handing over this repo to people interested in supporting it? |
|
+1 Please remove this RFC1918 IPv4 address verification via |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
Not stale. |
|
is not stale A proper solution of is_local() would compare the local address(es) of home-assistant with the address of emulated_hue and return false as they are on different networks. Any comparison of hard-coded addresses as this is doing is insecure. |
|
I've just reviewed this one and I am going to close this issue. Looking at our history and codebase, this change was made intentionally in: #17248 The reason is that this endpoint doesn't require authentication, and thus not something we want to every accidentally expose to the public. You could consider working around it using a VPN or other tunnels if you really want to work around that. If you want to suggest a feature, you should try our Community Forum: Feature Requests. If you have additional questions, feel free to join our Discord chat server. Thanks! 👍 ../Frenck |
|
Thanks for the suggestion with the VPN, but if you use a local network completely with public IPv4 addresses, no tunnel or VPN will help. All devices in the LAN then have public addresses, the LAN can still be secure. NAPT should never be seen as a firewall, it is a deceptive security. The solution implemented in #17248 is a big mistake and should never have been implemented in this way. It is a great pity that such design flaws are not corrected. |
|
@frenck - would there be opposition for adopting a branch of the Hue integration as the current maintainers are not interested in correcting the errors in the current code? I am happy to demonstrate how the current implementation has flaws. |
Home Assistant release with the issue:
Home Assistant 0.103.6
Last working Home Assistant release (if known):
n/a
Operating environment (Hass.io/Docker/Windows/etc.):
HASS.IO on Synology NAS (.SPK)
Integration:
/components/emulated_hue/
Description of problem:
The Hue Emulation is limited to RFC1918 IPv4 adresses; if running in a network with e.g. RFC 3927 addresses or with public IPv4 addresses (as in my setup), which is perfectly fine and valid, access to e.g. /api/pi/lights is denied with message:
{"message": "Only local IPs allowed"}
This is not mentioned anywhere in the docs.
There seems to be no option to work around this issue. The list of allowed IPv4 addresses seems to be hardcoded (see https://community.home-assistant.io/t/emulated-hue-only-local-ips-allowed/109852/4).
Please disable this check (I don't know what it is good for) or provide a setting to override this check.
Problem-relevant
configuration.yamlentries and (fill out even if it seems unimportant):emulated_hue:Traceback (if applicable):
Additional information:
The text was updated successfully, but these errors were encountered: