Shared Link / "scl" to "s"

[Pysio13]

Hello. My question concerns my recent issue with file sharing. Usually, my links were generated in this way: 'https://www.dropbox.com/s/'. However, lately, every file is being generated in this way: 'https://www.dropbox.com/scl/fi/'. Do you know a way to restore the old way of generating links? I just need old way of links, because game can't read new links

    Greet 😛

[JasonSilverDBX]

Hi everyone,

I am one of the Product Managers for our sharing functionality here at Dropbox.  I have read through every one of the posts in this thread and can understand your frustration.  Many of you are long time Dropbox users that depend on us to keep your content secure, and critically, to also make it easy to share. 

While we took quick action to deliver a fix to allow direct download from shared links (see posts here and here), it seems it did not completely solve the problem.  Some users on this thread have reported success, while others have not.

We very much hear you!  I do not have a solution to post here for you all tonight, but we are taking careful look at the use cases you’ve shared to provide an answer soon.  I will aim to post another update here by end of this week before the holidays in the US.  Please do continue to provide details or any additional failures you’re seeing as it is a huge help!

Jason Silver

Dropbox Sharing Product Manager

[Здравко]

---

@JasonSilverDBX wrote:

...

While we took quick action to deliver a fix to allow direct download from shared links (see posts here and here), it seems it did not completely solve the problem.  Some users on this thread have reported success, while others have not.

...  Please do continue to provide details or any additional failures you’re seeing as it is a huge help!

...

---

Hi @JasonSilverDBX,

Let me make some notes. A big Dropbox pain is the provided features documentation (including documentation related to shared links). I have no idea who is/are responsible for documentation, but as seem involved are too lazy. Yes, LAZY! Usually documentation describing particular feature is (or has to be; it's a good practice) available before the feature roll out. What happens now? New link constructions are on go, but documentation that describe them is... missing (at this post time). How many time is needed and how many has passed?! 🧐 That's something very confusing! What if you're using some service and its features appearance changes without notice? Would you be glad? Here is the same!

It's the same for many other things Dropbox related (not to say all). There are feature available from day zero, that are still without proper documentation (and unusable in this context). Take a look here for such an example (shared links unrelated). There are many other such examples.

I hope you can do something to improve this documentation inconsistency in general (not only links related).

[shonuff74]

No worries. Onedrive works. Keep your DB.

[aaronpanganiban21]

So it looks like (no shade here) a staff member marked it at solved. I didn’t, and I think I commented earlier that I’m leaving it open because it hasn’t been resolved yet.

I’m unsure why they’d do that unless it’s a way of protocol for them to keep tabs on the issue (like tallying the cases). But yeah, it’s far from fixed and if anything it might have gotten a LOT worse

[BenDBX]

Hi Everybody,

In order to properly track and update our users about updated link structure, I have created a new thread that specifically addresses the effect of this change in URL structure on third party apps and websites.

I will also be moving all comments on this thread relating to 3rd party apps and websites to the new thread, which can be found here.

This thread is open for continued discussion of the change in URL and how it has affected direct downloads and rendering through Dropbox.

Regards,

Ben

[JasonSilverDBX · Accepted solution]

Thank you @BenDBX  for splitting off a new thread specific to the 3rd party integrations issue, and especially for doing it in a way that migrates all the relevant posts to date!  To properly wrap up this thread, below is a summary.

Why the new "/scl" link format?

Dropbox is moving to an updated shared link architecture where links are based on the content being shared rather than on the user doing the sharing.  This new content-based link architecture is already in place for edit access links to folders and newly created links to files, and can be identified by the presence of an ‘rlkey’ parameter in the URL.  (They also begin with "/scl" instead of the previous architecture's  "/s".)  It is the rlkey parameter which grants access to the content.  That is why removing that parameter results in visitors having to sign in and request access.  I talk more about this transition in this forum thread.

Over the next few months, we’ll round out the shared link portfolio by bringing this new architecture to newly created view-only access folder links, or view folder links for short.

Direct Download on new link architecture is Solved

Regarding this thread on “direct / forced” download not working on new links, this should be solved since a fix was implemented 2 weeks ago.  That is, all new links should now function the same as legacy links for these purposes.  This can be accomplished in two ways.  

1. modifying the dl parameter in the URL
2. modifying using dl.dropbox.com or dl.dropboxusercontent.com.  

👉 In both cases you must retain the rlkey parameter for the URL to grant your recipients permission rights to access your file.

 

What is the DL parameter?

Anything following the ? in a URL are query parameters.  It’s worth reemphasizing that dl parameter in new links did not break and will continue to function identically to those in legacy links.  Manually changing the dl parameter does the following:

https://www.dropbox.com/scl/fi/<token>/path.jpg?rlkey=<token>&dl=0

• Default link. This will render the content in the Dropbox file viewer.

https://www.dropbox.com/scl/fi/<token>/path.jpg?rlkey=<token>&dl=1

• Downloads the content of the link (if the user has access to the content based on link settings). This query parameter takes precedence even if raw=1 is also added.

https://www.dropbox.com/scl/fi/<token>/path.jpg?rlkey=<token>&raw=1

• Directly renders the content in the browser (if the link has a public audience and no other restrictions). Note that this link has an HTTP 302 redirect, so the application or browser must be able to follow the redirect.

 

What are the dl.dropbox... modifications?

These are link transformations from the early days of Dropbox.  While we don't "officially" list these anymore in our Help Center, we are continuing to support them for now.  

https://dl.dropbox.com/scl/fi/<token>/path.jpg?rlkey=<token>&dl=0

• Replacing www with dl works exactly like a ?raw=1 link: this will directly render content for public links in the browser. It requires following an HTTP 302 redirect.

https://dl.dropboxusercontent.com/scl/fi/<token>/path.jpg?rlkey=<token>&dl=0

• Works like a ?raw=1 link, but the application or browser will not need to follow an HTTP 302 redirect to access the content.

[sj_usa]

I am receiving an error trying to download a .tmb file.  It was working 2 days ago just fine and for a number of years before this.

As of this morning, it's adding the /scl/fi to the file with a rlkey syntax, where it used to be /s without a rlkey parameter.  I tried removing dl=1 with raw=1 but that does not work.

How can I set up direct downloads?

[Rich]

---

@sj_usa wrote:

As of this morning, it's adding the /scl/fi to the file with a rlkey syntax, where it used to be /s without a rlkey paramter.  How can I set up direct downloads?

---

Refer to the post directly above yours, from @JasonSilverDBX.

[Justin P.2]

I'm a long-time Dropbox user, and I always use the MacOS Dropbox app so I can get the direct links via the Mac Finder or Dropbox app in the top menu bar.

In the last few days, I notice that newly uploaded files have even longer links than files did in the past, and every time I try to download a file to test the link, I get a pop-up message from Safari asking permission to download each file.

I'm used to Safari asking me to allow downloads from a certain website but after I give permission, it never asked me again. It's almost as if each file/link have their own domain because I now have to give permission to download every file I test.

The longer links are terrible and so is the new security behavior.

If anybody from Dropbox reads this, please fix this ASAP and make it work like it used to.

[Justin P.2]

Here is some more info:

https://twitter.com/MysteryRoomMKE/status/1681092910480084994?s=20