I am currently using the wireless tags integration. This integration sets up the wireless tags base station (192.168.1.128 on my network) to make URL calls to Home Assistant to pass data. These calls are of the form (where 192.168.1.61 is my HA server)
I am getting and have been getting this in the log for a while
2019-11-06 02:10:13 WARNING (MainThread) [homeassistant.components.http.view] Access from trusted networks without auth token is going to be removed in Home Assistant 0.96. Configure the trusted networks auth provider or use long-lived access tokens to access /api/events/wirelesstag_update_tags from 192.168.1.128
Reading the change summary for the current version, I’m not sure:
Should this still work?
Why am I still currently getting the warning on 0.100.2 if I have the configuration.yaml section
Will this integration / URL call work at all in the latest version?
What about REST sensor calls on the local network?
I could really use some help with this, I did the upgrade and now I’m getting this
2019-11-07 16:22:16 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from 192.168.1.128
What am I missing here, how do I tell HA that my local completely enclosed and secured home network on which I control all devices is completely trusted and should never be blocked?
I saw them but it looks to me from reading the release notes and the docs on the authentication methods that it should work which is why I went ahead with the upgrade, figuring perhaps the warnings on the earlier versions were generic warnings that were not verifying whether the auth was set up or not. I have actually been sitting here reading and re reading the docs trying to figure out what I’m missing. I know my trusted network section is working because HA recognizes it when I go to log into the UI from another machine. I would be fine with using oauth tokens but these calls have to come from a device where I do not control the HTTP header section so there is no way for me to add a token.
Direct authentication meant that you could make an authenticated request without a bearer token by making the request from a trusted network or appending ?api_password=X to the URL.
These features are still available as authentication providers (docs).
Or you can use a webhook-based-integration. A webhook is a unique hard to guess URL that can be used to send data to Home Assistant. Requests made to webhooks do not need authentication. Your webhook should be available from the internet, if you have a cloud subscription, the cloud will take care if this. You can find the cloud webhook URLs on your cloud configuration page.
Problem is the wireless tags integration automatically sets the URL on the device that’s calling HA so I don’t even have control over what URL it will use. I can do it a different way where I have more control without using the integration and I may have to do that but it just seems like there should be a way to call HA from a local IP using the trusted networks auth provider and the docs seem to suggest that but maybe not - I guess I’d like to just have a definitive answer on whether it’s still possible or not.
I read the documentation to mean you can access the web interface, but not necessarily connect via automated devices. That would be what the webhooks are for. This might call for an issue to be created on the integration github page.
That’s what I’m starting to think too. I think the integration might be a little light on developers right now, I actually set up a development system recently to try to dive into it myself but unfortunately I don’t have much time right now. Thanks for answering anyway, I think I may try to revert back to the earlier docker image for now and figure it out.
The only issue I have is when I restart HA, wirelesstags reverts the url to the old value (8123 port) so I have to update wirelesstags every time HA is restart.
Let me add my “me too” in here, I upgraded to 101.3 from 95.6 and my wireless tag integrations can no longer log in. I dislike adding a web proxy service to an already taxed pi3 and there are no other boxes in this network to host one. And I really need this integration to work, I will probably have to rollback to a previous version with trusted networks.
my understanding, is for the local support in the wirelesstag ethernet hub, the url field has a character limit that can not be upped per them (I asked in their google group https://groups.google.com/d/msg/wireless-sensor-tags/34gCMj6pKAM/PhJ4VGEjCQAJ ). Due to that limit there is no way to use the HA long lived token without a proxy. the code I use is really light weight and doesn’t really add any overhead. I even got it to work as a custom add-on to hassio. Like i mentioned thought the tag manager reverts the urls for local control whenever HA restarts.
It’s not the tag manager reverting the URLs it’s the wireless tag HA integration code - it updates every tag with update URL’s at every restart which is convenient if you add a new tag but frustrating if you need to change a URL manually.
I haven’t submitted a bug report because it seems like the author has not been updating the code - I want to be very careful here to mention that this is not a criticism or demand, I really appreciate the time he put into it and I’m sure like the rest of us he just has not had time to get back to it.
I am going to build a small proxy that will just pass along every request and block of data to HA with an auth token attached, thereby effectively completely disabling the security on the local network, which is what makes sense to me. I’m all for security but it seems to me there should be a way to trust local networks in as flexible and extensible a tool as HA. Just IMHO.
Has there been any change or progress in getting the wireless tag HA integration working without the frequent “Login attempt or request with invalid authentication from” messages? I’d prefer not to have to build the proxy if possible, but if that’s the only way I’m open to trying.
@tube0013 - can you elaborate a bit on how you got this to work as a custom add-on to hassio?
in the root folder on hass.io (the folder above config) create (if not already there) a folder called addons, in that folder create a new folder called json-proxy.
in that folder you’ll need to create 2 files - config.json and Dockerfile.
The config.json file: https://paste.ubuntu.com/p/JtcQj8f6Mg/
(The port in this file is the port that the tag manager will now use in the Local URL fields).
The file piece is a folder in your config folder called json-proxy.
inside another config.json - contents: https://paste.ubuntu.com/p/N8mxSGVpKc/
(Change to add in the url/ip of your HA instance and add the long-lived access token you create on HA, also the port should match what is in the addon config.json)
As I noted above the biggest challenge I haven’t overcome is that on a restart of HA the URLs on the tag manager revert to the 8123 port. I usually open the tag manager web interface and have the URL page open when I restart HA so I can just re-save the values on re-starts. I have tried to block communication from my HA ip to the tag-manager with my router firewall rules but that is either not working or not the cause of the urls changing.
FYI what I wound up doing is rolling up my own very simple VB proxy running on a windows machine that listens for updates from the URL calling from the tag manager and then forwards them over to HA by using the REST api to create sensors on the fly. The forwarded call to HA uses a long term token. The wireless tag integration has a couple of existing issues that have nothing to do with this new security problem so I kind of needed to get away from it anyway.