Over the air download via API fails today, worked yesterday.

Hello everyone. We have just come across this issue today. We also have a few hundred devices on the field and have been successfully doing OTA updates for TI CC3200 with Dropbox API since 2015 (back when APIv1 was still in use).

We are constantly getting links with 557 bytes in lenght and there is no feasible way to fix this in firmware for devices on the field.

Anxiously waiting for a fix!
 
Thanks!

Good news, this team worked on this, and was able to reduce the link length back to under 500 bytes. You should be able to request the shorter links again now. Please try it and let me know if you're still seeing any issues.

Please note, however, that the Dropbox API specification still does not guarantee a maximum length for this 'link' value. That being the case, please update your app(s) to accommodate a 'link' of arbitrary length (or at least, of significantly larger length).

I have also sent this along to the team as a feature request to codify a maximum length for the 'link' in the specification, however at this point I can't promise if that is something that will be done. The temporary link implementation on the Dropbox API backend is not trivial, and involves encoding certain authorization data in the link. The size of this data can vary.

Finally, an important security note:

Based on the context I've received around this issue, if I understand correctly, this is being used for updating devices over-the-air, by embedding pre-generated access tokens for a single specific Dropbox account directly in to the devices. The devices call a number of Dropbox API endpoints using that access token, such as /2/files/get_temporary_link (the result of which is used to download a firmware update payload).

The Dropbox API was designed with the intention that each user would link their own Dropbox account however, in order to interact with their own files. It is technically possible to connect to just one account as is being done here, but we don't recommend doing so, for various technical and security reasons, especially in client-side apps like this.

One of the main issues is that client-side apps can't keep secrets. A malicious user could extract the hard-coded access token from the app, and use it to access the Dropbox API directly to perform any operation (bypassing any access controls your app might have attempted to enforce). For instance, in this scenario, they could upload their own malicious payload, which would then be distributed to the other systems via the existing over-the-air update mechanism.

Of course, the actual difficulty to extract the access token and perform an attack depends on a variety of factors, and your organization can choose what level of risk you're willing to accept. Please contact a security professional for any general security advice.

For the above listed reasons though, I do not recommend using the Dropbox API in this manner. Instead, a typical CDN may be a better way to distribute updates. I've also sent this along as a feature request for a safe way to use the Dropbox API in this manner, but I likewise can't promise if this is something that would be implemented.

Hello Greg,

Please thank your team on our behalf and on behalf of 100K users, at least on our side.

Your statement is noted and we will proceed with firmware changes ASAP.

Hello Greg,

We have tested and it works.

Could you please send me dropboxe's address using in a private message (info at gcdis.com)

I would like to send you and your team a gift for Christmas.

Also do not forget to mention the team member names for the Christmas cards.

Hi Greg,

Thank you and your Engineering team.  We have tested the OTA on few Chips in field and it worked. 

Embedded Devices are limited by memory and this device CC3200 has very tiny memory. It will be good to know the maximum size of link that Dropbox might implement in the future. We are thinking of allocating 1200 bytes. 

Thank you Greg!

We are allocating 768 bytes for the temp link (up from 512).

For the other CC3200 users out there: it seems that increasing the size of OtaFileMetadata_t.cdn_url (on ota_api.h) is not enough! You can still get a memory leak on req_uri (in CdnClient_ConnectByUrl), as part of the temp link will be copied to this buffer which originally has 400 bytes!

We were able to find this leak just because, by chance, it was affecting a data structure holding proxy data, which breaks all communication!

If anyone knows of any other additional changes that have to be made in order to accommodate the larger Dropbox temp link please share here! Let's help each other out!

Thanks!

Hello Greg,

It seems that we are having problem again with the returned url, can you please check?

Kindly note that we did change our firmware update process to Amazon IoT but unfortunately we do have a significant number of users that did not update yet to the new firmware and are having issues because of the returned URL.

You can see for yourself that the API calls have been reduced noticeably. Nevertheless, as you already know, transition from one system to another is not linear as we don’t have the power to drive everyone in making the transition within the required time.

With this point in mind, we kindly ask for your understanding and support in returning links shorter for another 2 months. On our side we will put all our efforts in communicating a final notice to our customers so that they make the transition, thus eliminating api calls to dropbox prior to the expiration date.

George

IOT_Developer Thanks for the report! I'll be happy to look into this for you, but I can't make any promises. First, for reference, can you let me know:

• Is the issue again with the length of the link returned by /2/files/get_temporary_link?
• When did you start seeing this issue again?
• What length were you getting before then?
• What length are you getting now?

Thanks in advance! 

Greg-DB  Thanks for your prompt response. The issue again is with the link returned. 

It all started happening this monday.  Before that it was less than 400 bytes and we suddenly see it crossing 512 bytes which is the limit.

IOT_Developer Thanks! I'm not currently aware of anything that should have caused such an increase, and I also currently can't seem to reproduce that increase myself, nor have we received other reports of this, so we'll need to investigate this further. Would you be able to open an API ticket with additional details, e.g., a sample request and response (but please redact your access token), so we can investigate further? Thanks in advance! 

Hello Greg-DB ,

I did create a ticket.

It does not see as reuturn url issue any more though.

please check  the log below:

_ReadStatFile: ERROR in sl_FsOpen, status=-11
sl_extLib_OtaRun: call OtaClient_ConnectServer OTA server=api.dropbox.com
OtaClient_ConnectServer: http_connect_server api.dropbox.com
sl_extLib_OtaRun: OtaClient_UpdateCheck, vendorStr=Folder
OtaClient_UpdateCheck: call http_build_request /1/metadata/auto/
CdnDropbox_SendReqDir: uri=/2/files/list_folder
metadata file=/FOLDER/FILE, size=129084
sl_extLib_OtaRun: OtaClient_UpdateCheck, numUpdates=1
sl_extLib_OtaRun: OtaClient_GetNextUpdate: file=/FOLDER/FILE, size=129084
OtaClient_ResourceMetadata: call http_build_request /1/media/auto
OtaClient_ResourceMetadata: file flags=80,metadata flags=80
CdnDropbox_SendReqFileUrl: uri=/2/files/get_temporary_link
L0IYOW2YPF1-gz-x0T0FpxLLXQd_5ftBFoz1het0tnYCziQ_9cAAi-5wuV7P4bJM_Suyry27j05t3uwTHxjBUru-LBuud9k", "has_more": false}
0

Cannot find json fileOtaClient_ResourceMetadata: Error media json_parse_media status=-1
sl_extLib_OtaRun ERROR: OtaClient_ResourceMetadata

IOT_Developer Thanks! We'll look into it and follow up with you on your ticket shortly.

Hello Greg-DB ,

the issue has been fixed.

I would like to thank you and Moe for your ultra fast response.

Once again Dropbox has prooven it's value and definately has prooven that stands behind it's products.

George