I’m subscribing to Webhooks with a URL that looks like
https://<username>:<password>@<ddns address>:5556/webhook-rachio
The POST requests from the Rachio servers are not using the username/password in the URL and do not have an Authorization header. Is that working as intended?
We don’t currently support passing credentials in the webhook. A workaround would be adding an externalid and validating that like an OAuth token if you wanted to build in security.
Add a webhook to a device. externalId can be used as opaque data that is tied to your company, and passed back in each webhook event response
Not really a workaround. The web server is also used for other Webhooks, and all of them support credentials.
This is really a severe shortcoming of your implementation.
Maybe not the easiest workaround, but have you considered to limit the endpoint to a certain IP?
Here is an example for Apache .htaccess:
<Location /webhook-rachio>
Order deny,allow
Deny from all
# 54.69.249.10 is at least one address for api.rach.io, add more IPs as needed
Allow from 54.69.249.10
</Location>
Alternately, you can make the endpoint a secret https://ddnsaddress:5556/webhook-rachio-mV4uYIGCHaKQ, these days basic authization is far from secure (sent as clear text, just base64 encoded), authorizing via a secret URL is much more secure since only one endpoint could be compromised at a time, which is close to impossible with a proper SSL cert & enforcement.
Yeah, there’s lots of way to attack the problem, but all of them are going to require additional coding and probably changes to the other Webhooks that use the server (URL changes at least). This is a custom HTTP server embedded in a home automation system component.
Have you considered adding a free nginx proxy to the setup? You can add (example) basic auth prior to forwarding the traffic to existing code, while authenticating based on different factors (url, ip, etc…)
This is a home automation system. Just having to add port forwarding to the router is beyond the capabilities of some of the users. Requiring nginx is totally out of scope.
@FlyingDiver I’ll add that requirement to our backlog. To date we haven’t had this functionality requested from other providers.
@FlyingDiver I had the team add this to webhooks. I’m not 100% clear on the spec. Is it allowable to POST directly back to the URL that was given including the username:password values? Or is the intent to only have the Base64 encoded ‘Authorization : Basic ZnJhbno6cGFzc3dvcmQ=’ values and not have the username:password as part of the URL?
The user would specify the username:password in the URL they submit to you, but the Webhook client (your server, in this case) converts that to the authorization header as you’ve done above. And does not include it in the actual URL used for the HTTP POST.
If this is live, I’ll test it out tomorrow.
OK, I’ll give it a go then and report back.
Works!
