I already have my phones integrated into HA and I have defined zones and I have triggers that notify me when entering the zone, etc.
Why do I want Webhooks?
To post data to homeassistant for stuff that doesn’t have specific integrations, and to call automations from other systems.
But obviously it’s only useful to you, when you come across something that uses it.
Example - I use Tasker on my phone, so when I open the camera app, Tasker posts to a webhook which is the trigger for an automation. The automation snapshots the lights in the living room, turns them on, sets the colour to daylight, maximum brightness. When the camera app is closed, Tasker posts again to the webhook, and the automation recalls the snapshot - so the lighting is returned to it’s previous state.
So Tasker already knows how to do Webhooks? And Tasker is not an HA thingee?
The only thing I noticed when reading was the tracking stuff. Uh oh. Maybe I’m confusing it with OwnTracks. Crap. I’ve been reading too much stuff and starting to get confused. I’m a relative newbie with all this.
Nope - that’s the point of a webhook. It has no authentication. Any device or service that can make a web request can therefore make use of the webhook. Owntracks is using a webhook too yes, it’s exactly the same thing - owntracks posts to a randomly generated webhook, which means it requires no authentication.
I presume there is something that prevents somebody from issuing these requests to my HA?
If your Home Assistant is exposed to the outside world, then nope, nothing stops anyone from posting to the webhook, that’s the point of it. The way around that is to generate long complicated webhook URLs. I use: https://www.uuidgenerator.net/ and get 2 or 3 UUIDs (just remove the hypens) eg:
373bc411-2c21-4e8c-a956-acf2bac32c3e6d54e015-7ac1-43b8-9d2f-b63cb4f5eedd76e9c9f4-8192-4875-a6f6-fb6144d045bd
becomes
373bc4112c214e8ca956acf2bac32c3e6d54e0157ac143b89d2fb63cb4f5eedd76e9c9f481924875a6f6fb6144d045bd
that’s what stops people posting to your Home Assistant webhook - making it impossible for someone else to guess what the URL is.
Not if you expose HA to the internet.
Of course, it’s only a problem if you name your webhook something trivial, like test, so that people can hit /api/webhook/test. If you do the sensible thing and randomly generate something long then it’s much harder for people to find it that way.
1 Like
I’ll have to do more reading. Seems like a man in the middle could see that api string and issue themselves no?
Where is the best documentation?
If your Home Assistant is using SSL (and it absolutely should be, using the NGINX add-on, so Home Assistant itself is NOT directly exposed to the internet, and is behind the NGINX proxy) - then nope, a man in the middle can’t see what is being posted to that webhook. So taking my Tasker controlling my lights example, the automation is looking for a specific bit of information being posted to that webhook, if that information is missing, then the automation will not do anything. So even if someone did manage to find that webhook, they still would need to know exactly what data the webhook is expecting.
1 Like
It has been a couple of years since I did web development. I thought even when https, the "path "part of the URL was still exposed. But the body where the “data” would be would definitely be encrypted. I could definitely be wrong.
I can’t do an add-on because I’m running HA on a Synology box and that implementation doesn’t apparently support add-ons. My HA exposure to the internet is through Nabu Casa.
Thanks for all the information. I’ll have to go and digest it now…
1 Like
My Home Assistant access is via NabuCasa too. And yes you are absolutely correct, the path would be visible, to a man in the middle attack, but the post data would not be. As you are using NabuCasa, then your webhook would be even more protected - because NabuCasa already gives you a randomly generated URL and then you would have your randomly generated wehbook.
Again, even if someone somehow managed to guess the full URL, wehbooks are POST only, not GET, and they expect data, in the correct format.
Everything in the HTTP session is encrypted, but not information in the TCP and IP layer.
2 Likes
For what it’s worth…
I use webhooks so that my wife can toggle a few lights from her tablet without having to run Home Assistant.
What app do you use ? Tasker, IFTTT or some other generic HTTP requester ?
A link to the URL which opens the standard browser would be enough
It’s just bat file on the desktop:
@echo off
curl -d "" http://192.168.1.57:8123/api/webhook/officeLight42
1 Like
Are you answering me?
If so, it is not that simple because when you open a link in the browser, it opens GET request.
Home Assistant Webhooks doesn’t accept GET requests.
I’ve seen “curl” referenced, but I’ve never used “curl”. I never realized it was available on Windows. I just checked and it is. I always thought it was a Unix/Linux type thing. I’ll have to try to remember that.
I did realise your question was to expand the original thread. 
But yeah I just read that.
Never used eebhooks though
1 Like
You can config your webhook to accept any of: HEAD, GET, POST and PUT, requests