nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

BUG - Direct link to files created via /media API call return a corrupt URL!

De L.1

I noticed that direct links generated via the /media API are currently returning a corrupt URL. Not all file formats seem to be affected, but I can reproduce the issue for PDF and Office files.

According to the documentation, the returned JSON should look like this:

{
    "url": "https://dl.dropboxusercontent.com/1/view/abcdefghijk/example",
    "expires": "Fri, 16 Sep 2011 01:01:25 +0000"
}

However, currently the following JSON is returned:

{
    "url": "https://api-content.dropbox.com/1/files/auto/abcdefghijk/example.pdf?signature=1.uJpbEgcWOjAIBQ..1435610003.qbYUOzANtu_33g6uv6dJy0JcV9tjp-oF8nQCci_h2Mg",
    "expires": "Fri, 16 Sep 2011 01:01:25 +0000"
}

The url however is invalid and give the following error:

{"error": "Signature did not match. STRING_TO_SIGN was u'1\\nuJpbEgcWOjAIBQ\\n\\n1435610160\\napi-content.dropbox.com\\nGET\\n/1/files/auto/abcdefghijk/example.pdf'"}

Has something changed in the API or is it a (quite severe) bug. If the /media call has changed, where can I find more information about this?

Find more posts tagged with

API

Abuse

Comments

Rich

Moved to API forum.

Greg-DB

Thanks for the report. We're looking into it.

Greg-DB

We've disabled this change for the time being. To help us investigate, can you copy an actual sample of where/how you tried to access the returned URL? Can you check if an extra ' or %27 was added at the end? (I encountered the same issue where my terminal included the ' from the end of the quoted string in the JSON when opening the URL in my browser, for example.)

De L.1

Thanks for your quick reply! Unfortunately I don't have the actual JSON response anymore, the only link I still could find is the following:

https://api-content.dropbox.com/1/files/auto/Test%20Out-of-the-Box/%C3%89tonne%C3%AEz.docx?signature=1.uJpbEgcWOjAIBQ..1435610702.N8XYasB2hZ6nElVLSL5A5LnzBZp5SBo9gehuiejgJtc (which just works now...)

Which I received by calling createTemporaryDirectLink($file) in Client.php (PHP SDK 1.1.5) call. There seems to be no extra ' or %27 in the URL.

I am not sure if this is the information where you are looking for, if not just let me know.

Greg-DB

Thanks! It sounds pretty likely you ran in to the same (or a similar) issue then, since the link you have works.

How exactly were you testing it though? E.g., were you manually copying and pasting it into your browser or something, or did you click it from your terminal?

De L.1

My app just does the API call and redirects the user to the URL from the JSON response. Noting fancy actually...

However, I also noticed that it isn't possible to the ?raw=1 or ?dl=1 (render a file or force a Save as) parameter in those new URLs via the old /media URLs. Is that true?

Greg-DB

For the most part, the dl and raw parameters aren't meant for the /view links to begin with, since the /view links already return the content directly. Those parameters are really meant for www.dropbox.com/s/ which go to a preview page by default. I think the only difference is the Content-Disposition header, which isn't currently configurable with the new format. Is that behavior relevant in your app?

Ok, since the change we've enabled/disabled didn't affect the returned links themselves, just whether or not you get the new format, and since your link itself does work, it sounds like it was just something like what I described. That being the case, we're re-enabling this for your account. Please give it another try and let me know if you can reproduce it and how you do so. Thanks in advance!

De L.1

Thanks for your answer. It's a little bit late here, so I think I mixed things up... The issue was indeed caused by the addition of ?raw=1 to the new URL...

However, I am still having issues. The following link doesn't do anything for me in Chrome(43) and IE(11):

https://api-content.dropbox.com/1/files/auto/Test%20Out-of-the-Box/Getting%20Started.pdf?signature=1.uJpbEgcWOjAIBQ..1435625123.JlvQfjBKXW-mc41a4Xfp9pGYfOwqptbQtPjQB-jvayA

If I look into the Chrome Console, I get the following errors:

1) [Report Only] Refused to apply inline style because it violates the following Content Security Policy directive: "default-src *". Either the 'unsafe-inline' keyword, a hash ('sha256-1kQs8h_ra9YlH-s6eZbKdSD_cn6Ljcz2Rv60pJnk_eY='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

2) Error in event handler for runtime.onMessage: SecurityError: Failed to read the 'cookie' property from 'Document': The document is sandboxed and lacks the 'allow-same-origin' flag.

Besides that, it indeed creates an issue for me. My app wants to download (for example) files via a Save As dialog directly via a short lived url. Until now, I called /media to receive a temporarily link to the file in the form of

https://dl.dropboxusercontent.com/1/view/e9bvl1qlepzw8vd/Example%20Out-of-the-Box/__TESTFILE__.txt

I could change that into

https://www.dropbox.com/s/e9bvl1qlepzw8vd/Example%20Out-of-the-Box/__TESTFILE__.txt?dl=1

to force a save as dialog.

However, with the new URL that isn't possible anymore. It is possible that I used the API in the wrong way in the past, but how should I do it properly?

Greg-DB

Thanks! Just adding ?raw=1 would do the same thing in the new format, since it already has parameters added with a ?. You should instead parse the URL in order to add a parameter.

Anyway, thanks for the new details. We're disabling this for you now and will investigate potential solutions.

Also, the links from /media weren't really meant for use in the browser. If you want /s links anyway though, you can use /shares instead, and those links respect the raw and dl parameters. Those aren't short-lived though. It sounds like what you ideally want is a way for the user of a web app to be able to download a file from the Dropbox account directly in their browser, without having to pass the data through the app's server. That's not really something the API currently solves well, but we'll consider that a request.

De L.1

I am not sure if this is going off topic, we can also discuss it via email.

The app I created is a WordPress plugin allowing users to display their Dropbox files directly on a WordPress page without the need of shared links. Users that want to download a file, don't get their hands on a shared link, but instead the short lived url is used to download the file.

I have the same kind of plugins for Google Drive, Box and OneDrive and their API's all include a (short lived) direct download link to the file. And honestly, I think that it should be part of the Dropbox API as well. I don't see a reason why I should first download files to the apps server via the /files call before I can pass it to the user. It makes more sense to let the user download the file directly via the Dropbox servers.

Greg-DB

That's certainly a reasonable request, and I've sent it along to the right people as a feature request.