I have a rule to unlock my front door that is triggered by a cloud endpoint, so that I can make a shortcut in the iOS Shortcuts app. Works quite well! Then I discovered there's an option for local endpoint as a trigger, and I figured for security reasons might as well switch to that. So I added the local endpoint trigger, copied the URL, deleted the cloud endpoint trigger, and saved the rule. Before modifying the shortcut on my phone, I wanted to test it to make sure it did NOT work, and much to my surprise, it DOES still work! How can that be if the only trigger in the rule is now local endpoint? The URL for the cloud endpoint should not do anything, but it does.
That didn't change the access token for this rule. Remove the rule and recreate it.
2 Likes
I get that. I see that the access token portion of the URL is even the same in both the local and cloud URLs. But since the URLs are different and I removed the cloud URL as a trigger from the rule, how is it possible that it still triggers the rule?
Ah, I think you just uncovered an unintended hole in the way this works! It should be checking for the 'authority' to respond to the endpoint, and it isn't doing that.
2 Likes
Looks like it.
I wonder if I were to rebuild the rule with a new access token and local endpoint, and then manually construct a cloud URL with the new access token, would the rule run?
I think so. I know how to fix this. In fact, Maker API would have the same issue but it checks the 'authority' whereas RM does not.
Authority checking aside, I'm still very curious how a thing that is not defined as a trigger for a rule could in fact trigger that rule. How does that work?
My unsolicited guess: if you've ever created a Hubitat app that uses OAuth for endpoint mappings, by the time it gets to the app, it all looks the same regardless of whether the request came from a local or cloud source. (That part is true, not a guess.) You can check a specific value in the data to see where it came from (request.requestSource for anyone who might be finding this via search and cares), but most apps wouldn't do this unless they had a specific reason to care. RM inadvertently not checking, since the default behavior doesn't inherently distinguish anything, would be my guess. 
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
