Support Dropbox /scl/ type links

[porg]

A link which I created just one week ago

https://www.dropbox.com/s/f7oy7f3ydh0kpyo/WordPress-Greenshift-v6-4-3-Breakpoint-Desktop-is-normal.png?raw=1

• ✅ Works fine to embed that image in a forum.
• ✅ wget above-url downloads that file well too.
• Dropbox now refers to dropbox.com/s/* as "legacy links".

A link which I created today

https://www.dropbox.com/scl/fi/uvcdieskhipwbmernql8h/WordPress-Greenshift-Grid-item-order-New-UI.png?raw=1

• ❌ Visiting this URL in my web browser results in an error page.
• ❌ Embedding that image in a forum results in a broken src.
• ❌ wget above-url downloads no PNG anymore.
• Dropbox now refers to dropbox.com/scl/* as "new links".

Related News

https://www.dropboxforum.com/t5/Create-upload-and-share/Shared-Link-quot-scl-quot-to-quot-s-quot/td-p/689070

Proposal / Request

In face of those Dropbox API upgrade, could you please make the generated links to work as the old links?

• Everything in ~/Dropbox/Public/ when requesting a link being immediately "readable by world"?
• No need to set flags/permissions per each file (would like to avoid any management overhead if possible)

[porg]

Some personal note

• Update here, update there, dependency here, needing to take care of this too, …
• Although being an early Millenial who has participated in the entire digital revolution both actively and passively, with quite some fascination and passion, I more and more feel that:
  • Digital technology makes your life not simpler but more complicated.
  • For baby boomers and elder anyhow.
  • But even for versed digital professionals the whole overhead which "staying up to date" and "fear of missing out" bring with them is really huge.
  • I'm sick of this.
  • Rant over 😉

[porg]

Your script:

• ✅ already starts the link with /scl/fi/
• ✅ Still ends with my custom preferred argument raw=1
• 💡 What is missing in the link is the new rlkey argument. Then it should work again.

Workaround for now:

• Get the link in Finder with right clicking your desired file → Context menu → Copy Dropbox Link.
• Then change the default argument dl=0 to raw=1 if you want.

[nk9]

Huh, thanks for alerting me to this. It's strange that the API is returning the wrong links, I wonder if Dropbox is aware of this. Anyway, I can have a look.

[porg]

• As I wrote in the comment above, it is partially already reflecting the changes.
• Maybe using #3 where your script manipulates the arguments of that URL, cuts off that new rlkey argument or does not include it (whatever way you construct it).

[nk9]

Hmm. It's true that if you use the --query argument to manipulate the returned query, it will just overwrite what was there before. I've pushed a code change to address that issue, which will be important now that the rlkey= query argument will be required.

However, that may not be the problem in this particular case. For me, anyway, when I fetch links, I'm not getting the /scl version, so there is no rlkey. They work, though. I guess I can check if they are still wokring later, but if they aren't it seems like that's likely to be a Dropbox API issue, not anything with this script.

Thanks for the link to the Forum post, it points to this other post. Still a bit confused , TBH. That second post gives details about what types of links are being generated in the new vs old style, and when. Although it sounds like, at least as of a month ago, the rollout had been paused.

[porg]

For me, anyway, when I fetch links, I'm not getting the /scl version, so there is no rlkey.

1) Old files and their links remained untouched.

• They are out in the wild, so Dropbox certainly did not want to break old links. 2) Try uploading an entirely new file and get its link.
  • Still with those new type links many integrations and workflows that users were accustomed to, broke due to the new URL pattern. 3) Maybe you were not included in the rollout!
• The linked forum thread mentioned that they rolled this out to some users only (by what criteria I dunno).

[nk9]

Good points, thanks. I tried on a new file, but same old link style. So I may not be part of the rollout. LMK if you learn any more.

[porg]

"Dry swimming" exercise:

• Can you develop a version which makes sure that the rlkey=… part gets/remains included in the URL, without you having the possibility to test it.
• I could then test it with my account which is already "new link enabled" and give you feedback whether it works.

[porg]

Btw, I was one of the very early users of Dropbox, maybe a criteria which got me included.

[porg]

From what I learned meanwhile I propose the following for get_dropbox_link.

From what's officially summarized here

• define some base URL formats which one can set as preference.
• and/or pass as an argument to the get_dropbox_link script! That way one could create two different keyboard shortcuts which point to different Automator scripts which call get_dropbox_link with different arguments.

Then on top of that apply the preference from #3.

Dropbox "New Link" Base Formats

link-new-preview

https://www.dropbox.com/scl/fi/<identifier>/filename.png?rlkey=<content-key>&dl=0

link-new-download

https://www.dropbox.com/scl/fi/<identifier>/filename.png?rlkey=<content-key>&dl=1

• Safari: Fails sometimes, cause yet unknown: Either too many redirects or browser caching issue.
• wget <url> → Creates ugly filename (the last URL part as is).
• wget -content-dispositon <url> → Creates intended filename (passed via HTTP Content-Disposition header)

link-new-raw-redirect

https://www.dropbox.com/scl/fi/<identifier>/filename.png?rlkey=<content-key>&raw=1

link-new-raw-direct

https://dl.dropboxusercontent.com/scl/fi//filename.png?rlkey=

• I assume this is ideal for forum embedding etc, as no HTTP 302 redirect occurs but instead directly a HTTP 200

[porg]

Aditionally I asked Dropbox to offer a rlkey-free URL pattern for files located in the special location ~/Dropbox/Public/ which should continue to get read:everybody as their default "hassle-free easygoing permission":

https://dropbox.com/scl/fi/<flag>/<identifier>/file-within-dropbox-public.png where flag could be: n (normal) | dl | raw.

I very much hope they keep the possibility for a laissez fair link type.

[nk9]

OK, you can now amend the arguments without overwriting the rlkey. I've also moved the APP_KEY and ACCOUNT_TYPE variables into the config file to simplify upgrading. This should be working now, but you'll have to let me know since I still can't create rlkey links yet.

[porg]

News: Dropbox has totally rolled back the /scl/ link type

• Updated your script file to newest version.
• Tested with existing files and created some new files and dirs:
  • ~/Dropbox/Public/file-created-during-the-short-new-link-type-era.png
  • ~/Dropbox/Public/test-2023-08-15a.txt
  • ~/Dropbox/Tmp/test-2023-08-15b-Not-in-public-folder.txt
  • ~/Dropbox/Test-2023-08-15c-Dir/test-2023-08-15c-fresh-file-in-fresh-dir.txt
• Interestingly all these (!) now returned an "Old style" link, both via:
  • get_dropbox_link.py
  • Finder > Context menu > Copy Dropbox Link (official DropBox Finder extension)
• Dropbox seems to have totally (!) reverted this New Link API:
  • Not only for the special location ~/Dropbox/Public/ but seemingly everywhere, including also new files in existing directories and new files in new directories.
  • The rollback was so radical that even the "New link" style links (which were supposedly permalinks!) were rolled back (leaving a few forum posts of mine, whose editing timeframe closed meanwhile, with orphaned IMG links of this ill-fated era).
  • This can only be summarized as a big failure: Total rollback, not even a redirection for those few new link types which got out into the wild. This is diletantism of an early stage Startup (Dropbox anno 2007 maybe) but not an established top notch IT company in 2023. I would not have believed this to happen to such an IT giant, had I have not experienced it myself.

[porg]

Dropbox Base Formats

• I had proposed this idea for the "new" (meanwhile aborted) /scl/ type link
• Still makes sense to also offer these for the classical /s/ type links, especially the raw ones without redirection are seemingly the right one for embedding (fewer redirects!).
• Currently #3 allows to change the URL argument, whereas "base formats" would go a bit further and also use different sub/domains accordingly.

link-preview

https://www.dropbox.com/s/<identifier>/filename.png

link-download-argument

https://www.dropbox.com/s/<identifier>/filename.png?&dl=1

link-download-subdomain

https://dl.dropbox.com/s/<identifier>/filename.png

link-raw-redirect

https://www.dropbox.com/s/<identifier>/filename.png?&raw=1

• HTTP 302 redirect

link-raw-direct

https://dl.dropboxusercontent.com/s/<identifier>/filename.png>

• I assume this is ideal for embedding, as no HTTP 302 redirect occurs (slower) but instead directly a HTTP 200 (faster).

[porg]

Issue: Kept "open" until having a confirmed test - Reports welcome

• get_dropbox_link.py anyhow interacts with the Dropbox API and hence always (should) return the most recent correct URL pattern for the supplied file.
• 310b32c as commented integrates the rlkey argument which is mandatory for /scl/ type links in the --query part when using the optional #3
  • This should work in theory. But is untested! Reports appreciated.
  • @nk9 never had /scl/ links hence could not test them
  • I had /scl/ links, but by the time I had 310b32c installed, Dropbox rolled back /scl/ links (for my account at least)

[porg]

The other proposals raised in the comments above are now a standalone followup issue:

• 13