We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.

Forum Discussion

theTutor's avatar
theTutor
Explorer | Level 3
5 years ago

get_temporary_link with zip files causing Google Chrome warning

Hi

 

Google Chrome (83, Mac) has started giving me a 'Dangerous File' warning whenever trying to download zip files specifically served by the 'get_temporary_link' API call. I have 'Safe Browsing' enabled (set to 'Standard'). Until recently I have experienced no issues using this API method (using it for over 2 years now).

 

Apart from virus scanning etc, we've performed the following to isolate the cause:

 

1) The exact same files download without problem when accessing via a standard 'shared' dropbox link (i.e. with dl=1 appended to end)

2) The same files download 100% fine when downloaded through Chrome within our Dropbox account.

3) The exact same files download fine when uploaded to other file hosts. For example, Amazon S3.

4) We have created new zip files that contain nothing by a single plain text file and these are still causing the warning, but only when served via the 'get_tempoary_link' method.

5) We've pasted the temporary dropbox link directly into the Chrome address bar to rule out any potential issues with the php script we are normally using to serve the files

 

This only seems to affect zip files (have tested PDF and txt, no problems there). The only constant variable that causes the warning is the use of the 'get_temporary link' call. Unfortunately I don't have any indepth knowledge of the Dropbox API so am not able to test other API methods, nor am I able to see anything obvious that might be causing this.

 

Can anyone think why this might be any issue? I assume it's either the URL structure itself, or the output headers. 

 

The header is

 

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 29 Jun 2020 08:37:18 GMT
Content-Type: application/zip
Content-Length: 60328012
Connection: keep-alive
cache-control: max-age=0
pragma: public
x-dropbox-request-id: 9292cd205582aa9dc8b7b280e644fd75
x-robots-tag: noindex, nofollow, noimageindex
referrer-policy: no-referrer
etag: 1586602502895794n
accept-ranges: bytes
x-content-type-options: nosniff
content-disposition: attachment; filename="somefile.zip"; filename*=UTF-8''somefile.zip";
content-security-policy: sandbox
x-webkit-csp: sandbox
x-content-security-policy: sandbox
Vary: Origin
X-Server-Response-Time: 566
This is the code we are using to generate the temporary file:



$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://api.dropboxapi.com/2/files/get_temporary_link");
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Authorization: Bearer ' . $dropboxKey,
'Content-Type: application/json') );
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, "{\"path\":\"/".$record["file"]."\"}");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

$data = json_decode(curl_exec($ch), true);

if (curl_errno($ch)) { echo 'Error:' . curl_error($ch); }
curl_close($ch);
$filepath = $data['link'];

 

Any advice appareciated!

  • This should be fixed now. Please let us know if you're still seeing any issues like this.

  • Greg-DB's avatar
    Greg-DB
    Icon for Dropbox Staff rankDropbox Staff

    Thanks for the report. I just tried this myself and I was able to reproduce this warning in Chrome with a temporary link to a zip file with some junk in it. A txt file worked fine for me though as well.

     

    I also accessed my two temporary links directly, and the only differences seem to be, aside from the file data itself:

    • the "Content-Type" header: "application/zip" vs. "text/plain; charset=utf-8"
    • the lack of the "Vary: Accept-Encoding" header
    • the "x-dropbox-request-id" header value (both randomly generated)
    • the "etag" value (though this is opaque anyway) 
    • the "content-disposition" header "filename" value: reflecting the respective file name and extension for each, ".zip" vs. ".txt"

    Of those, I think it's likely the "Content-Type" and/or the "content-disposition" that Chrome is suspicious of (since .zip could potentially hide something more dangerous than .txt would), perhaps combined with different levels of trust of the Dropbox API server host as compared to others like S3.

     

    Unfortunately, it doesn't look like there's anything for us to fix on our side, since the HTTPS response is valid in both cases, and the logic for this warning is controlled by Google of course. Dropbox also doesn't offer ways to configure the specifics, e.g., the headers, of the response (though we don't know what specifically is causing Chrome to decide to show this anyway).

     

    I'll raise this with the team, but I can't promise if this is something we'd be able to resolve. You may wish to raise this as an issue with Google.

    • theTutor's avatar
      theTutor
      Explorer | Level 3

      Thanks for the reply. If it helps, I've copied the headers below for the same file downloaded through Amazon S3 (which was considered safe by Google), their headers are more 'threadbare'.

       

      But I agree, ultimately this seems down to some internal logic at Google, and while I will report this I wonder if Dropbox could also report this themseleves, considering this is an issue that you've independantly confirmed and one that is likely to affect all dropbox customers using this API call (and potentially other API calls) for delivering zip files?

       

      HTTP/1.1 200 OK
      x-amz-id-2: 7MxPN6hDhv+Rmb9kvfQN64Z2WnSeGI5jhHvP2s6OGpSo7B4ORWyFQ/A+TnOzkTtqN8AAKnj6He0=
      x-amz-request-id: A1EA9FD1D0064990
      Date: Mon, 29 Jun 2020 08:32:31 GMT
      Last-Modified: Tue, 02 Jun 2020 11:31:27 GMT
      ETag: "72b5b016974907dcadc1644b08ff28c6-4"
      Accept-Ranges: bytes
      Content-Type: application/zip
      Content-Length: 60328012
      Server: AmazonS3

       

      • Greg-DB's avatar
        Greg-DB
        Icon for Dropbox Staff rankDropbox Staff

        Thanks! Yes, we're also looking into what we may be able to do about it on our side. I'll follow up here with any updates.

About Dropbox API Support & Feedback

Node avatar for Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

5,877 PostsLatest Activity: 12 months ago
325 Following

If you need more help you can view your support options (expected response time for an email or ticket is 24 hours), or contact us on X or Facebook.

For more info on available support options for your Dropbox plan, see this article.

If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!