You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Acces thumbnail images for PDFs
I'm using Dropbox to store PDF files, and my external application needs to programmatically access a thumbnail image of the first page for each of these PDF files.
These thumbnail images need t...
Greg-DB wrote:...
ЗдравкоYou mentioned you're getting an "Internal Server Error" on some piece of functionality. Can you share the details so we can look into it? Thanks in advance!
Hi Greg-DB,
Sure, I can. In 2/files/get_thumbnail_v2 description can be seen that connection to this end point can be authenticated using App Authentication. Such type of authentication assumes possibility of using both POST and GET request. Also, authentication and argument should be able pass either as header or as parameters and both are assumed equivalent. Yes but no!!! When I pass headers using GET request:
curl -s -S -o ~/dump.jpg -D - -u "<app key>:<app secret>" -H "Dropbox-API-Arg: {\"resource\": {\".tag\": \"link\",\"url\": \"<shared link>\"},\"size\": \"w64h64\"}" https://content.dropboxapi.com/2/files/get_thumbnail_v2
The result is as expected. Here <app key> and <app secret> are valid ones. <shared link> is valid link to a file able to produce thumbnail. In my case I use a link to arbitrary PDF in my account.
When I try pass the same (or equivalent thing, according to documentation) as parameters:
curl -s -S -o ~/dump.txt -D - -g "https://content.dropboxapi.com/2/files/get_thumbnail_v2?arg={\"resource\":{\".tag\":\"link\",\"url\":\"<shared link>\"},\"size\":\"w128h128\"}&authorization=Basic%20<base64 key&secret>"Where <shared link> is the same as above and <base64 key&secret> is produced according documentation from <app key> and <app secret>. Follows the result (response body is empty):
HTTP/1.1 500 Internal Server Error Server: envoy Date: Wed, 23 Feb 2022 19:17:38 GMT Content-Type: text/plain; charset=utf-8 X-Content-Type-Options: nosniff Cache-Control: no-cache Vary: Dropbox-API-Arg, Authorization, Accept-Encoding Content-Disposition: attachment; filename=unspecified Content-Security-Policy: sandbox X-Webkit-Csp: sandbox X-Content-Security-Policy: sandbox Content-Security-Policy: sandbox allow-forms allow-scripts X-Robots-Tag: noindex, nofollow, noimageindex Strict-Transport-Security: max-age=31536000; includeSubDomains; preload X-Robots-Tag: noindex, nofollow, noimageindex X-Dropbox-Response-Origin: remote X-Dropbox-Request-Id: 81e8c25c686642a3b479972366796ab9 Transfer-Encoding: chunked
I have no idea what's wrong here! As a consequence, such request can not be encoded in a simple link. The same is the result when I try to in web browser (I checked in Firefox). That's it.
Greg-DB
Dropbox Staff
Dropbox StaffЗдравко Thanks! That's helpful. I just checked on this, and it looks like that failure is due to an invalid app key and/or secret value, so please double check your values. Additionally, there seems to be a bug on our side with how we handle that error case, resulting in the 500 Internal Server Error being returned, instead of a useful error message/response. I'll ask the team to fix that up.
Greg-DB wrote:... it looks like that failure is due to an invalid app key and/or secret value, so please double check your values. ...
Ok, Might be, but there is no reliable way I check it. The following is the way I use to get authentication values. I repeated the test with the same result.
curl -s -S -o ~/dump.txt -D - -g "https://content.dropboxapi.com/2/files/get_thumbnail_v2?arg={\"resource\":{\".tag\":\"link\",\"url\":\"<shared link>\"},\"size\":\"w128h128\"}&authorization=Basic%20$(echo "<app key>:<app secret>" | base64)"Here used values are correct for sure; they are same as above (first command), but fails still (second command). Is the used algorithm wrong? 🤔 I thought it's the same as described, but...
- Greg-DB
Здравко You need to use "echo -n " instead of just "echo" in this case. When you don't set "-n", echo includes a trailing newline character which will corrupt your encoded app key/secret value.
Waww🤦🤫... that's something really stupid from my side.
But the issue is still there. 🤯 Just the response changes to "Conflict" with body:
{"error_summary": "not_found/", "error": {".tag": "not_found"}}Despite the values are correct. I just checked all them once again. 🤔 Using the same values I can download a thumbnail of the pointed file (values passed as headers).
If you have performed a successful query, can you post the corrected template? 🙏 (just correct the one I posted above; not only the ending new line but whatever is else too)
Add: Full response, if can help:
HTTP/1.1 409 Conflict Server: envoy Date: Wed, 23 Feb 2022 21:27:34 GMT Content-Type: application/json X-Content-Type-Options: nosniff Cache-Control: no-cache Vary: Dropbox-API-Arg, Authorization, Accept-Encoding Content-Disposition: attachment; filename=unspecified Content-Security-Policy: sandbox X-Webkit-Csp: sandbox X-Content-Security-Policy: sandbox Content-Security-Policy: sandbox allow-forms allow-scripts X-Robots-Tag: noindex, nofollow, noimageindex Strict-Transport-Security: max-age=31536000; includeSubDomains; preload X-Robots-Tag: noindex, nofollow, noimageindex X-Dropbox-Response-Origin: remote X-Dropbox-Request-Id: 8302bd4020194fcfb1c64a0201ecae46 Transfer-Encoding: chunked
- Greg-DB
Здравко Your code does work for me, as long as I add "-n", and plug in my own app key/secret and shared link. That "not_found" error should indicate an issue with the shared link in this case. Make sure you're supplying a valid and accessible shared link value and are encoding it correctly. For instance, it appears your "arg" URL parameter value is not encoded, though it's not clear if that is how you're sending it or if that's just for illustration purposes.
For example, here's a working version of your code, with the "-n" and an encoded arg containing a sample link:
curl -s -S -o ~/dump.txt -D - -g "https://content.dropboxapi.com/2/files/get_thumbnail_v2?arg=%7B%22resource%22%3A%7B%22.tag%22%3A%22link%22%2C%22url%22%3A%22https%3A%2F%2Fwww.dropbox.com%2Fs%2F1xzftgs96f8ksbx%2Ftest.pdf%3Fdl%3D0%22%7D%2C%22size%22%3A%22w128h128%22%7D&authorization=Basic%20$(echo -n "<app key>:<app secret>" | base64)"Thanks Greg-DB,
It's not exactly missing URL encoding, but you drive my to right direction and I found out what's wrong. Since I have used non ASCII symbols in the file name this seems confuses the function. I have no idea why? There is an easy workaround: I just stripped filename in the link; the name isn't mandatory there. Everything works now. 😉
You can take a look if this can be fixed. To reproduce, just rename your "test.pdf" to something like "тест.pdf", for example. It still works while passed as header, but not as parameter! Anyway... I successfully bypassed the issue. 👍
Thanks again!
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
