Identifying the user for external API calls

I’m building a smartthings app for a specific use-case inside a multi-unit building where a smart things button will make an external API call to my own server, which will then unlock the front door (which is not Zwave or Smart Things compatible,… but only accessable through a REST api).

I am using Groovy’s HTTP POST call to do this, and I got it working.

But, I need a way of identifying that user, for logging reasons, so that I could, ideally send some type of userID, userName or something along with that POST call. Is there a way to get any identifiying information from within Groovy, from the hub?

It looks like I can get a hubID, but is that it?

Hub ID, Location ID, SmartApp instance ID (and possibly the source SmartApp ID) are all available.

Account ID / User ID is not supplied for … privacy reasons?

Yes, you can, although it’s undocumented and can change any time without notice. Try adding this to your device code: "Owner: ${device.owner}"

This will print the following to your log output:

xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx 12:41:46 PM: info Owner:

I.e. it will print the email address of the registered user. Kinda handy for spamming, if you know what I mean. :slight_smile:

I suspect @tgauchat will cry “privacy alert” now, but it is what it is. :sunglasses:



This is a serious loophole that I personally think SmartThings should fix ASAP.

@slagle, @jody.albritton?

What’s the privacy concern? I’m missing it. It would be valuable for troubleshooting and many other potential use cases in my opinion.

A SmartApp is supposed to only have information granted to it explicitly by the user (i.e., authorized Things, and data about the SmartThings Account Location).

Information about the Account (i.e. email address and even the Account UUID) is considered private.

As per the 3rd Security Researchers report, SmartThings was chastised for allowing customers to install unvetted SmartApps in their Locations (via copy / paste) than could access non-explicitly granted functions (like setting lock PIN codes).

A Trojan horse SmartApp, using the owner data above could easily posted this along with the geographic location of the owner’s home to a website. A serious privacy vulnerability.


So it’s more to do with providing an attack vector than a privacy concern.

I would posit that this is a risk associated to technology in general and not unique to ST. I’m free to install any application I want on a windows machine. There has to be a level of discrimination on the part of the user to understand the potential risks. Otherwise, we end up with a closed system and a loss of fidelity.

Apple for example takes a walled in garden approach which locks down 3rd party applications that must meet their requirements (arbitrary/anti-competive at times).

One of the things that drew me to this platform was it’s openess. Perhaps ST could implement some code review logic similar to that of android apps which provides a summary of the application permissions and resources needed by the app so that novice and non-devopler types can make informed decisions about the apps they install.

That’s one way to put it…

But I assert that no SmartThings Customer expects their Email Address to be revealed to any third-party unless explicitly requested.

More generally, please refer to the very big hubbub that resulted from 3rd party smart home security researches eviscerating SmartThings and is described in this Topic below (and the half-dozen or so Topics that are linked to it).

The access to device.owner absolutely falls into the same general category of concern. I hope that @slagle or @dlieberman or designates give it the same level of response.

1 Like

By the way, I totally think this is a great idea and quite appropriate for this situation, but — seriously — do you think SmartThings has any chance of getting to even close to this within the next 12 to 24 months?

I hope their priority is on published SmartApps and DTHd.