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

@jpimbema wrote:
...
Now, I've read that a link containing /scl/fo/ is an edit link. Why do some folders produce a link containing /scl/fo/ and others /sh/ while we explicitly ask for a read only share link?
...

Hi @jpimbema,

There are 2 folder link formats (one is being in depreciation /sh/ and other - the successor /scl/fo/). By now the two formats are in use (the old one is not dropped automatically, but all new links are in new format). That doesn't mean the particular link is "can edit" type, but could be. That's something you have control on and can check.

In folder share settings is a dropdown menu where you can select from "can view" or "can edit" as well as see what's selected now (the same is for file share settings as well). You can change your default settings from your account sharing settings. See on section "What people can do" and change to appropriate if needed. 😉 The last is valid for both on site created link and API created links. While using API, in the API itself is no control what type of link to be produced - not yet at least. For API you may control your link types only by using default setting in your account (i.e. by hand). Let's hope this will change in future.

Hope this helps.

Yes, starts with this code:

@jpimbema, Is that, you posted, used only for Dropbox Embedder or for other things too (like Dropbox Chooser)?

Jay

Thanks, I've moved this thread to the API forum for our colleague to provide more specialized assistance.

@Jay, It's still not clear if particular issue is API related!!! That's why asked how it's used! That may be nothing API related at all.

Only for the embedder.

@jpimbema wrote:
Only for the embedder.

Thanks @jpimbema.

@Jay, your mistake - nothing API related!

As I said, check the actual link you have created - don't suppose it. In your account, on right of the folder, you want to show, is a share icon (it displays only when cursor hovered). Push it and see what's on the dropdown menu there (what's selected actually).

@Здравко when I click the icon it shows Iedereen met deze link: kan weergeven translated: Anyone with this link: can view

That's the actual link I copy into the embed code.

@jpimbema wrote:
...: Anyone with this link: can view

That's the actual link I copy into the embed code.

In such a case your issue doesn't nothing to do with "edit link". It's just not "can edit" link type in such a case, but "can view". To be sure, you may recreate the link and check anew - the link you're using may be created at time when something else has been selected.

Next step would be to check the link in incognito window and change the ending "dl=0" to "dl=1". When hitting enter key, does the link start download or shows some message? (you don't need to download - cancel the download - important thing is what starts to happen) If some error appears let us know what it is.

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:

изображение.png

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:

@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.

@Greg-DB wrote:
..., so you'll need to create new shared links for the fixed behavior.

Yes, but no!!! Now, with new link the behavior changes, but stays incorrect; now with new link to the same file https://www.dropbox.com/scl/fo/25bzgyfsnf7ewps37i25i/AD-38IrNkvYcv0eHaopJz6s/GOLF-P-WE-AU-BLACK/%231134_GOLF-P-WE-AU-BLACK.eps?rlkey=60509kpyry3hmb2mx00gjpo5h&dl=0:

If I click "Back to files", it asks me log in! 🤷

I generated the above link in the same way as previous one with folder pointing link: https://www.dropbox.com/scl/fo/25bzgyfsnf7ewps37i25i/ADMm0_m7MuQGroaOEsfGVRo?rlkey=60509kpyry3hmb2mx00gjpo5h&e=1&dl=0

It doesn't matter dl=0, dl=1, or raw=1. 🤔 Something still goes wrong despite of no more 2 redirections. Redirection to the link root folder gets replaced by redirection to error HTML (page) in all cases.

Is there some error on my side?

PS: Dropbox doesn't even let to me access my own file! (even when I'm logged in) Before I was able to access my file at least.

$ curl -X POST -u '*************:************' -H 'Content-Type: application/json' -d '{"path":"/GOLF-P-WE-AU-BLACK/#1134_GOLF-P-WE-AU-BLACK.eps","url":"https://www.dropbox.com/scl/fo/25bzgyfsnf7ewps37i25i/ADMm0_m7MuQGroaOEsfGVRo?rlkey=60509kpyry3hmb2mx00gjpo5h&dl=0"}' https://api.dropboxapi.com/2/sharing/get_shared_link_metadata | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2063  100  1882  100   181   1053    101  0:00:01  0:00:01 --:--:--  1154
{
  ".tag": "file",
  "url": "https://www.dropbox.com/scl/fo/25bzgyfsnf7ewps37i25i/AD-38IrNkvYcv0eHaopJz6s/GOLF-P-WE-AU-BLACK/%231134_GOLF-P-WE-AU-BLACK.eps?rlkey=60509kpyry3hmb2mx00gjpo5h&dl=0",
...

@Здравко Thanks for the new sample! I'm raising this with the team.

@Здравко That should be fixed now. Please let us know if you're still seeing any issues with that. Thanks!