Clicking files in embedded Dropbox leads to registration screen instead of direct download

I created a new link and pasted it into the embed code, changed dl=0 to dl=1.

Cleared the cache of the browser. Reloaded the page where I embedded it.
Now when I click one of the files on the frontend, a new windows opens and I get a splash screen asking to register. Unless I click the download icon that appears when hovering over a file, then the download starts immediately in a separate window.

This behavior with the splash screen doesn't appear with the link containing /sh/ in the url, which puzzles me. Then the download in a new window starts immediately.

Hi again jpimbema,

I just reproduced the issue and yes, I now recall that there is still unresolved incompatibility (not full compatibility at least) between Dropbox Embedder and new link format (especially folder links), unfortunately. Dropbox Embedded "forgets" that rlkey needs to be kept in nested file links. 🤷 It drops this link parameter and invalidate the link in fact. The entire dropins need redesign. Let's hope this will be done soon. 😉

Good luck to all of us.

Thanks for the report! While the Embedder isn't part of what we call the "API", it is a developer tool so I've moved it to the Developers section.

Anyway, this is a known issue with using this type of link in the Embedder. We're looking into it and I'll follow up here once I have an update.

Greg-DB, Let me add something here. Yes, there was issue related to Dropbox Embedder itself ("was" because the current one is different and fully covers/blurs the previous, so no very clear - the issue me and you discussed above is now invisible). The current issue is Dropbox core issue! This issue affects everything. It's easy to reproduce - just create some shared link (to either file or folder) and after open it in web browser in incognito mode try download the content of a file (directly or indirectly pointed there). What is going on? This is neither API, Embedder, or any other developer tool issue. Even more: for Dropbox shared link to folder, try navigate inside (again in browser, but the same is reproducible in API and Embedder) and copy link to something inside (either file or folder). What does happen when you close the current browser and try open the link, just copied, in new window (again in incognito mode)? Does it open the desired target? 🤷 or not exactly 🙋....

As seems, somebody has created new mess/bug. Why when is something going to be roll out, it's not tested carefully enough in advance?! 🤦 Such a hurrying up leads to issues... I believe most user don't meet this still, but soon the complains will rain.

Здравко Thanks for the note. Just to make sure I'm reproducing the same thing you are, can you clarify what happens in your testing when you say "try download the content of a file (directly or indirectly pointed there). What is going on?"? What result do you get?

For reference, when I try that currently, I get an option to either "Log in or sign up" or "Or continue with download only", and that "Or continue with download only" option does successfully download the file for me. (And for comparison, when clicking on a file in the Embedder I instead get the registration screen, without the option to download the file, as described in the original post here.)

Oops... sorry. Before there was copy link feature... I by mistake tried copy to account, but the rest is the same.

.... Note also that in the popup is not the file name, but the shared folder name! Even when I fetch the file link (using either the page code or API), replacing dl=0 to dl=1, leads downloading entire folder (zip file), not the actual file the link points to.

Try play with:

Is the resulting link usable for something?

Здравко The URL to a particular file, with the file in the path of the URL, should point to the file in particular, and support downloading just that file in particular when using dl=1. I tried that and it did work for me.

Note though that it's possible to get a different URL when just viewing a particular file from its parent folder, which would still refer to the folder, and so would download the entire folder when using dl=1.

Here's a sample of the two different cases I just tried:

• https://www.dropbox.com/scl/fo/gq0pr3z3ojtsz8v6bzk8g/h?dl=1&preview=test.jpg&rlkey=lobujmcdn3dgn6j2vhpkm6zuz
• https://www.dropbox.com/scl/fo/gq0pr3z3ojtsz8v6bzk8g/h/test.jpg?rlkey=lobujmcdn3dgn6j2vhpkm6zuz&dl=1

---

Greg-DB wrote:

ЗдравкоThe URL to a particular file, with the file in the path of the URL, should point to the file in particular, and support downloading just that file in particular when using dl=1. I tried that and it did work for me.

...

Hm...🤔 It's fine that it did work for you, it don't work for me though. 🤷 Yes, I understand the examples you gave me, but I'm trying with the link I posted above. Two examples follows - using curl and Firefox (I cut some parts for clarity).

Here is curl result:

  Trying 162.125.69.18:443...
* Connected to www.dropbox.com (162.125.69.18) port 443 (#0)
...
> GET /scl/fo/25bzgyfsnf7ewps37i25i/h/GOLF-P-WE-AU-BLACK/%231134_GOLF-P-WE-AU-BLACK.eps?rlkey=lg5fi44eft8u5u5lnjcarhdzj&dl=1 HTTP/2
> Host: www.dropbox.com
> user-agent: curl/7.81.0
> accept: */*
> 
...
< HTTP/2 302 
< content-type: text/html; charset=utf-8
< location: https://www.dropbox.com/scl/fo/25bzgyfsnf7ewps37i25i/h?dl=1&rlkey=lg5fi44eft8u5u5lnjcarhdzj
< pragma: no-cache
< referrer-policy: strict-origin-when-cross-origin
...
< x-dropbox-request-id: f8384f71b3c6489ca429a77235e46a6a
< 
...
> GET /scl/fo/25bzgyfsnf7ewps37i25i/h?dl=1&rlkey=lg5fi44eft8u5u5lnjcarhdzj HTTP/2
> Host: www.dropbox.com
> user-agent: curl/7.81.0
> accept: */*
> 
...
< HTTP/2 302 
< content-type: text/html; charset=utf-8
< location: https://uc23afd9ebc7da3e839dd61472d1.dl.dropboxusercontent.com/zip_download_get/B0UJkehYIkc4NCs7x-5Ru2rwCONfHUxVI_yMMLDk4FdqQiSazhbrYILXZhtEnsR7c_0UVD4xltif1PmBDIOqXT8FV_oKUvDnbQVWRj8MbXXb2A#
< pragma: no-cache
< referrer-policy: strict-origin-when-cross-origin
...
< x-dropbox-request-id: 94824c8a0945494a9d157b543251e9f7
< 
...
> GET /zip_download_get/B0UJkehYIkc4NCs7x-5Ru2rwCONfHUxVI_yMMLDk4FdqQiSazhbrYILXZhtEnsR7c_0UVD4xltif1PmBDIOqXT8FV_oKUvDnbQVWRj8MbXXb2A HTTP/2
> Host: uc23afd9ebc7da3e839dd61472d1.dl.dropboxusercontent.com
> user-agent: curl/7.81.0
> accept: */*
> 
...
< HTTP/2 200 
< content-type: application/zip
< cache-control: max-age=0
< content-disposition: attachment; filename="#1134.zip"; filename*=UTF-8''%231134.zip
< original-content-length: 252188
< pragma: public
< referrer-policy: no-referrer
...
< x-dropbox-request-id: 09d96923cc4c4a8799c18fc3e493b255
< 

 And here is Firefox result:

GET /scl/fo/25bzgyfsnf7ewps37i25i/h/GOLF-P-WE-AU-BLACK/%231134_GOLF-P-WE-AU-BLACK.eps?rlkey=lg5fi44eft8u5u5lnjcarhdzj&dl=1 HTTP/2
Host: www.dropbox.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0
...
HTTP/2 302 
content-type: text/html; charset=utf-8
location: https://www.dropbox.com/scl/fo/25bzgyfsnf7ewps37i25i/h?dl=1&rlkey=lg5fi44eft8u5u5lnjcarhdzj
pragma: no-cache
referrer-policy: strict-origin-when-cross-origin
...
x-dropbox-request-id: 52a873ae1aa64d4eaff23d74038f9c6e
...
GET /scl/fo/25bzgyfsnf7ewps37i25i/h?dl=1&rlkey=lg5fi44eft8u5u5lnjcarhdzj HTTP/2
Host: www.dropbox.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0
...
HTTP/2 302 
content-type: text/html; charset=utf-8
location: https://uce1c6fed04edc93ba42aed539fc.dl.dropboxusercontent.com/zip_download_get/B0WB6Ib2rn4mBNQKw1Y-jE_Fe7hnwmTa3YiTbfOOkew1WHmhzxGzk-BNLOsdnVEaag-cvlqrS5tGkeOJQTfx3LwQoqLCfKzFBlz29w9VtiCSLg#
pragma: no-cache
referrer-policy: strict-origin-when-cross-origin
...
x-dropbox-request-id: 07d17b937a7942ba86e649126517a835
...
GET /zip_download_get/B0WB6Ib2rn4mBNQKw1Y-jE_Fe7hnwmTa3YiTbfOOkew1WHmhzxGzk-BNLOsdnVEaag-cvlqrS5tGkeOJQTfx3LwQoqLCfKzFBlz29w9VtiCSLg HTTP/2
Host: uce1c6fed04edc93ba42aed539fc.dl.dropboxusercontent.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:123.0) Gecko/20100101 Firefox/123.0
...
HTTP/2 200 
content-type: application/zip
cache-control: max-age=0
content-disposition: attachment; filename="#1134.zip"; filename*=UTF-8''%231134.zip
original-content-length: 252188
pragma: public
referrer-policy: no-referrer
...
x-dropbox-request-id: c98eac79aefc4fee94cf207343cf97ce
X-Firefox-Spdy: h2

It is 100% repeatable! Few more groups of x-dropbox-request-id if could be useful to identify what's going on:

c3cee03ed1ee40188328d460eda288d6, 15eba251a8264d8f978d07e8c93d27ca, 63e8a5985be94d51bbdec370ad661328

7a96542d82be4af09b18017366587b4e, c3af3bc2f45d4b1885e2b7366ac0e7bc, 81c01b5a3c8746da8f1bf6f992a11246

586cddd3a4b54d6fb320dfae28c96170, e94ecc4e9f914b20a0ce60d2d278b459, efc81fabe5b1485b970ea6efe9098b09

That came up from nothing...😕 Can you take a look what's up? 🧐 As seems this appears selectively - for some links only (I cannot see still what provokes this behavior).

Thanks.

Здравко Thanks for the sample! We'll look into it.

This issue is now fixed for new shared links. Please note that previous existing shared links will continue to display this behavior, so you'll need to create new shared links for the fixed behavior.