Subscribing to device by device id?

General Discussion
1

from this post … seems subscribing to devices by device id should work.

when trying … this is the error in the log. trying to figure out if i got something wrong or it is no longer supported?

6:50:42 PM: error groovy.lang.MissingMethodException: No signature of method: physicalgraph.app.api.SubscriptionApi.subscribe() is applicable for argument types: (java.lang.String, java.lang.String, java.lang.String, java.util.LinkedHashMap) values: [9101c6789-6784-445e-98e1-a5b456341225, motion.active, motionEventHandler, …]

thank you.

2

Per the Documentation subscribe() takes a Device (or list/collection of Devices) as a parameter, not a Device ID.

https://docs.smartthings.com/en/latest/ref-docs/smartapp-ref.html#subscribe

This is to prevent a SmartApp from storing the Device ID and then continuing to subscribe to it after the Customer has deselected the Device from the list of Authorized Things. That is a security violation.

While hacks may work, they are security violations and should not be used.

1 Like
3

once you have subscribed to a device and dont use unsubscribe … the smartapp will stay subscribed to that device from the last subscribe … wont it?

if yes … then the implementation really does little to make it secure.

4

Good point… that may be a loophole.

When a Customer changes the list of authorized Devices, however, it is typical for subscriptions to be recreated in the updated() method. I don’t know if that implies past subscriptions will be invalidated first.

Of course, a lot of this will change with the “new” API, which has both broader and finer granularity options for authentication

And … well… I’m still not sure why you would want to use Device ID for subscriptions instead of Device. Yes; I know it makes some stuff convenient, but I believe the typical workaround, when necessary, is to use the Device ID to lookup the Device object (in the particular input map), and then use the Device object.

(Hopefully someone will chime in with more practical experience on this. I lean heavily towards specs and theory.)

5

true. but the way security is being enforced here does not really protect from a bad actor.

yeah havent had time or need to play with the new APIs yet.

gives me the flexibility of subscribing to devices that may be selected in one copy of the child app in another copy of the child app without requiring the user to specify the same device in both places. its about user convenience.

6

Sure… but I still contend it gives the SmartApp coder too much convenience to access Devices from the Customer without explicit authorization (in each child app).

So whether it adds “much” security or not, I hope that the Device cannot be accessed except via the Device Object. The ID should not be sufficient. That was the original intention of the architecture and the documented API for subscribe().

7

explicit authorization could be granted in the parent app then each child app could subscribe to any of the devices that are authorized in the parent app based on various combination of changing conditions.

this is just security through inconvenience :slight_smile:

1 Like
8

Yup… That’s why hoping the new API cleans this up. I’m optimistic.

9

Earlier today I was looking at some code that did this:

def updated() {
	unsubscribe()
	subscribe(humiditySensor1, "humidity", humidityHandler)
}

Perhaps this is the sane thing to do…

1 Like