Well, I hope not, since this request is to implement functionality for the official Hubitat drivers for Shelly devices. Well, streamline it, since I've already figured out ways to do what I need, but it's definitely not 'elegant'.
It's 'breaking' or as you point out, 'breaking more' the Security model that was foundational. If that model was strictly a ST compatibility feature, then abandoning it might already be accepted. I can't predict and it's a model that I can't find any reason to dislike... so far 
Yeah... but read through my other posts here.
Right now, I can raise events on any device. I can subscribe (using websocket) to every event that occurs on the hub, regardless of whether it's a child device or selected as an "input". I can get the name and DNI of every device on the hub, and use that in an app to send events to them.
Heck, I can even access anything that's a "command" on a device like so
http://hubIp/device/runmethod?id=${deviceId}&method=on
Nothing I'm asking here isn't already possible.
I'm pretty familiar with this concept since it's the primary mechanism of HubConnect I'm still very much an EventSocket proponent. All 4 of my Production hubs are still using HubConnect, and both my Development hubs use HubConnect. I have a HubMesh connection between the two 'puddles', mostly to be familiar with setup of HubMesh.
Yeah, I could just use 'eventsocket' in the drivers of my Shelly BLE devices, but that's a LOT of websocket parses for 'not for me' messages and very few for 'oh, this event was for me'. It would be a VERY bad way to do it, since each device would have to process every event on the hub. It would be way better to have a much lighter weight 'only send the events for this device to this device' subscription system available, hence the ask here.
I've often described EventSocket as 'drinking from a firehose' and I agree that it's the wrong choice for your issue. HubConnect, when used to mirror most/many devices on a hub, EventSocket is a reasonable option, but HubConnect does offer a non-EventSocket path as well. And taking it even further, an external HubConnect Proxy Server was added to do all the filtering. All my Production hubs use that proxy server (living on my headless Mac Mini media server) while my Development pair do not, mostly to retain a 'one-of-each' experience.
And just to be clear, I am NOT proposing a proxy for your Shelly issue That would be gruesome.
Yeah. It seems very reasonable for something that would only ever be ran as a single instance on each Hubitat, and would be handling all/most of the devices, for sure.
But for me, the notion of HE not adding this for "security reasons" is silly, since it really doesn't break any security. It just streamlines things that are already available.
And not to mention that Shelly devices aren't the only WiFi devices that can act like BLE gateways. This feature would open the door for a Home Assistant "Bluetooth Proxy" type driver too.
1 Like
New one on me (although it is documented for apps) - sounds like a security flaw that should be patched.
1 Like
Eh, it's "documented":
Seems pretty intentional.
And just removing it would break a bunch of apps that currently use it. Plus that's hardly as much security issue as being able to put something like this in an app:
void turnEveryDeviceOff() {
1..10000.each{ dev ->
Map params = [
uri: "http://127.0.0.1/device/runmethod?id=${dev}&method=off",
requestContentType: 'application/json',
contentType: 'application/json',
textParser: true
]
asynchttpPost('turnEverythingOffCallback', params, null)
}
}
That'll turn every device that has an "off" command off on your hub. Well, every one that's got an ID of 10000 or less, which is pretty sure to be every device for most people. Or worse have it call "unlock" and it'll unlock every door.
Malicious apps and drivers can definitely be an issue, but breaking a bunch of functionality that people are using presently, without any secure alternatives being provided doesn't really make things better.
Merely raising an 'unlocked' event on a device driver (without actually unlocking anything) is minor in comparison to the ability to call the unlock() command on the device and actually cause the door to unlock.
The device/runmethod is another one I'd nominate for removal/patching.
Well, the UI itself uses it. So that would be tricky to remove. You could require a session token, but then how does the UI code get said token, in a way that you couldn't just mimic from an app or driver?
Short of having mandatory log-in username/password I don't see a way to remove that endpoint from being usable in a driver. And I wouldn't be in favor of mandatory username/password on something that's never exposed to the internet. It's just extra friction. And it very well may already be blocked if you have the hub security thing enabled. I don't, because that would just add annoyance for no benefit for me, so I couldn't say whether or not it's blocked by that.
True it might take moving some components back hub side to mask it appropriately, and that would probably break some things I like being able to do, but from a security posture it might be appropriate. 
Regardless, been down this rabbit hole too long so time to let it go...
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
