using markus70171234@gmail.com as userid registered to myopenhab and mypassword as password
Due to the fact that myopenhab requires an e-mail address there are 2 @ in the URL, which might confuse Rachio’s cloud backend. When I open this URL in a browser it comes back into the binding, so I would say in general it works. However, when I register this URL to the cloud service nothing happens.
Is there a way to use the uuid instead of e-mail in the URL? or something wrong with the syntax?
Rachio documentation says:
HTTP basic authentication is supported for webhook URLs. To enable HTTP Basic authentication, prepend username:password@ to the hostname in your webhook URL. We will send the credentials in the HTTP header. For example: https://username:password@www.mywebhookurl.com
The username:password fields are Base64 encoded and provided as a header value:
HTTP
Authorization: Basic ZnJlZDpmcmVk
Have you tried to URL encode the first @ or both of them? It’s not unusual to have an email address as a username. I’ve successfully use basic auth this way in Tasker before, but I don’t know if it was smart enough to do the URL encoding for me behind the scenes.
The challenge there is that the browser is definitely doing all sorts of URL encoding behind the scenes. What happens with wget or curl? I don’t know if those automatically URL encode or not and if they do, I bet there is a command line option to turn that off.
curl accepts the url encoded e-mail address, but nothing changed on the Rachio side
I need to debug the binding and check what’s in the current webhook list
I also created a post in the Rachio community
That’s what Rachio shows as an example: https://username:password@www.mywebhookurl.com
so they expect/support the seperator for the hostname
I depends on their parser, it need to support url decoding or take the hostname after the last @
I’m pretty sure that adding username:password@ in the URL is a purely client based feature and that the client is responsible for then adding those to the Authorization header in the actual HTTP request. I don’t remember seeing anything in the HTTP spec about URL based authentication, and we are using a popular node module for handling basic auth, so if we could support it, i would think our library (passport js) would support it as well. From what i can tell nearly all the browsers have removed this feature as it’s a security hole for end users.
The binding submits a webhook registration providing the URL
Rachio Cloud parses this strong, splits into credentials and URL
makes the http call and adds the credentials to the http header
myopenhab.org accepts the credentials and forwards the request to the local OH instance
In this case
I have to encode the webhook url properly
Rachio needs to support url-encoded credentials or proper parsing when 2 are included
myopenhab.org sees a http request with basic auth (or not)
This comes down to: What das Rachio support/expect? Maybe I get an answer from their community or support.
On the other side: Why do I login with the registered e-mail address to myopenhab.org? That already exposes some personal information. I would prefer registering with a userid and having my e-mail address only for password recovery. I don’t feel comfortable with portals using the e-mail address as userid. And finally: this would bypass my problem here
Assuming this is in fact the source of the problem which is not at all guaranteed. It’s just the first suspect.
But as you indicate, it is going to be up to Rachio to tell you how to make it work.
As for the use of email as the login, that is an incredibly common practice. And since you are communicating with myopenhab.org via HTTPS, the only things that know the email address are the two end points as all the communication in between are encrypted. On the Rachio side, they too use email as the login username so they already know this personal information.
