Removal of Undocumented Device Type Data Storage Option - 1/19/2017

Announcements
1

As of 1/19/17 we have updated some undocumented functionality in our Device Handler base. We have limited S3 access to no longer allow sharing s3 assets across devices. We have found the feature to be of limited use internally and we have security concerns in its current state and therefore will not be expanding it to a fully documented and supported feature of the platform. We have shut it down but are investigating other options to allow short term storage to S3 for devices and SmartApps. But, as of now we have no immediate timeline to add the functionality.

Our Image Carousel capability (used by 6 internal device types) has relied on this capability and we have implemented a hotfix in the platform to allow for Image Carousel devices to continue to store and retrieve images as before. At the switch over, any device with the image carousel capability will lose access to the images currently stored at the time of the deploy (12PM PST on 1/19/2017) but all installs of Image Carousel capable devices will immediately begin to populate and access images correctly from the deploy forward.

Custom device types that rely on the undocumented and unsupported method getS3Object will no longer access S3 data correctly. We apologize for any inconvenience.

To allow users to still be able to access the data they are storing via the storeImage method a new method is being added:

ByteArrayInputStream getImage(String name)

This method will handle converting and closing the S3Object for you. The name parameter corresponds to the name used to save the image. Images saved to S3 before the change will not be available but all new images saved after the release will be retrievable. Note: image names saved are limited to alphanumeric, “_”, “.”, and “-” characters.

As we investigate the needs for a storage mechanism for larger data than our Device State storage allows, we will certainly let you know.

We do sincerely apologize for the inconvenience and hope that you can understand that security is always out number 1 priority.

2 Likes
2

Tim could you share an example of how this would be to store and retrieve images with carousels or is one of the ST DH’s on github updated to use this?

3

Also I don’t see this API documeted in the ST documentation page

4

It’s not yet documented. But not because we aren’t going to, we forwent documentation so we could get this out. Will have a engineer step in and explain.

5

Yes please do because hubAction returns a bucket and a key when a camera returns a picture, getS3Object was being used to retrieve that image. What’s the recourse now?

6

Tim could you share an example of how this would be to store and retrieve images with carousels or is one of the ST DH’s on github updated to use this?

The storeImage method uploads the image to S3 as well as creating an event with details on how to access the image. When you open a device with carouselTile in a mobile client it should ask our cloud services for a list of image events created by the device and then should fetch those images.

7

Luke the issue isn’t the carousel, when using hubAction and the camera returns an image, the hubAction doesn’t return any Body (only a header). So instead we used to provide an option to hubAction to redirect the output to the S3 (hubAction.options = [outputMsgToS3:true]) and then retrieve that image using getS3Object and then store it using storeImage, so with getS3Object gone how does one retrieve the image returned by the camera in response to a hubAction?

9

@gausnes comments please, it would good to either fix hubAction or provide an alternative way to retrieve the content sent via hubAction which was done through the S3 cloud earlier. I’m thinking that ST didn’t think this one through completely.

3 Likes
10

So this breaks any local hubaction of the image format type? Thanks for the heads up.

Any workarounds or do I have to go back to hacking another solution?

1 Like
11

If that’s true then it just broke all 20 of my D-Link camera DTH… yay :frowning:

4 Likes
14

Video or stills?

15

video works, still images do not

1 Like
17

Yeah video works because its local. Stills were killed off today

1 Like
19

As you can imagine, this change has negatively affected a lot of users. Could you post a work-around here for all of us to see?

4 Likes
21

@Belgarion is your Amcrest DTH effected by this too?

22

Unfortunately, yes. :frowning:

1 Like
23

We understand this is a inconvenience. While we wish we had more time to notify… our security concerns overshadowed this. I don’t think you want us putting security on the back burner.

As a result we had to shut this down immediately. Since we are DIYs at heart we want to be able to provide a way to retrieve the image. As a result we are looking into adding a method to allow retrieval of images using a specific method.

4 Likes
24

Oh and as a side note…

In our research (pretty extensive) there is no evidence of this potential security issue being exploited.

1 Like
25

It would have been nice to give a heads up to users of that particular functionality instead of just shutting it down with no notice at all. I was giving praise recently when you proactively identified users affected by platform changes that impacted some versions of CoRE just a few weeks ago and now this. Is some consistency too much to ask for?

5 Likes
26

So, what’s the rush to disable this feature without providing a workaround then?

7 Likes