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 😛

[Duycode]

Hi! I had a problem with "get_shared_link_metadata" api. My links file contains "rlkey". My app has been granted permission required scope
"sharing.read". Status 409 Conflict when calling sharing/get_shared_link_metadata. Please guide me how to fix this problem. Thanks

[Здравко]

---

@Duycode wrote:

... My app has been granted permission required scope
"sharing.read". Status 409 Conflict when calling sharing/get_shared_link_metadata. ...

---

Hi @Duycode,

I created a download script sometime ago that uses, by the way, metadata too. Just checked it and seems to work still. Use it as a guide. 😉

Hope this helps.

[Aion]

This really isn't a good enough alternative. The new format breaks a lot of situations, such as media embedding in an application such as Discord. There really should be another API to generate a direct-access URL. Why you think it's okay to completely upend current workflows and not care about certain use-cases is beyond me. I'm looking into alternate storage solutions to take my business elsewhere in the meantime, unless this gets resolved, and I'm sure others are too.

[Elde]

I am not sure if it is directly related to your issue, but I came here for a similar problem with the new format of the download links while working on linux:

I used to download files through the wget comand:

wget https://www.dropbox.com/s/blahblah/file.tar

while trying to use the new links in this way:

wget https://www.dropbox.com/scl/fi/blahblah/file.tar?rlkey=123456789&dl=0

I had the problem that everything that came after the ? in the link was appended to the file name, so I had a file called:

file.tar?rlkey=123456789etc

It took me a while, but I found in a similar post I could use '--content-disposition' flag to the wget command and problem solved. I used it like this:

wget --content-disposition "https://www.dropbox.com/scl/fi/blahblah/file.tar?rlkey=123456789&dl=0"

Here is where I found the answer: 

Re: Why was a new key added to share links? No lon... - Page 4 - Dropbox Community (dropboxforum.com...

[porg]

Ironic that all those seeming established web giants handle the pillars of the web — The LINK and the PERMALINK — quite laissez fairs.

This comment adds a certain pun and irony to the whole discussion:

@Justin P.2 wrote:

Here is some more info:

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

---

When this was posted it was still Twitter. Meanwhile Twitter.com now redirects to x.com. Haha!

[PieroP1]

Hi. I don't understand why up to last week a link to a file was created in this way: https://www.dropbox.com/s/abcxyz/filename.mp3?dl=0  and now is created in this way:
https://www.dropbox.com/scl/fi/abcxyz/filename.mp3?rlkey=(values)&dl=0
Thanks for your help!

[Megan]

Hi @PieroP1, welcome to our Community! 

I've merged your post under the similar, initial thread regarding this issue, just to keep everything under the same place. 

Feel free to have a look around, and let me know if you have any questions.

Thanks! 

[porg]

First some sad honest truth: Your New Link API partial rollout was nothing less than a disaster. So many complaints and hundreds of integrations which stopped working. For a company your size I don't understand how such an unthoughtful rollout could happen.

Now to some concrete feature request WITHIN that new landscape:

As a Dropbox user I want my URL to be

• as short as possible
• as beautiful and transparent as possible (as few arguments as possible, if then with short variable names and short values)
• if you insist on the rlkey then put it after the identifier token, but not as an argument, which are always at the end of a URL!
  • To be a psychologically trustworthy link the "…-file-name-end.suffix" should still be visible for abbreviated URLs  (in some device/usage contexts users only see an abbreviated URL! If that's "cryptic stuff" only, and no "…fileend.suffix" in sight anymore, it becomes distrustful.)
• provide a possibility for URLs without a rlkey, like in elder versions everything in ~/Dropbox/Public/ defaults to read:everybody, then no need for a key
• no redirects (or as few as possible) for reliable embedding
• browser caching working reliable

URL pattern general

https://dropbox.com/scl/<options>/<identifier>/<content-key>/file-anywhere.png

For a file within ~/Dropbox/Public/ which gets a "totally easygoing treatment":

https://dropbox.com/scl/<options>/<identifier>/file-within-dropbox-public.png

options: n | dl | raw

• n as in normal (or a similar short/intuitive flag, e.g. "p" as in preview)
• dl as in dl=1
• raw as in raw=1

As these are binary toggles and anyhow mutually exclusive only one of them will be at its token position. Totally intuitive.

Options could also be the last part before the filename.

You have to do usability and best practise research yourself, how URLs are abbreviated in most software/device contexts. To my knowledge:

• Start…  — Not too common I think.
• Start…End — Common — Options at the beginning plus filename at the end are readable. That's the abbreviation which is least prone to URL hacks, but ofc there are still tricks like legit-sounding-subdomain.com.malicious.domain/badvirus.exe?f=bogus-but-innocent-sounding-filename-towards-the-end.jpg . But overally this is the most balanced/common one AFAIK.
• …End — Also Common — Then options and filepath as the last tokens would be ideal.

[yl4882]

I am able to render my images on my website using the dropboxusercontent format (link to the thread). The images work fine on mobile browsers like safari, chrome. However, I noticed that if I open the site in a mobile app using in-app browser, such as Facebook Messenger, Line, the images were not able to be retrieved. Does anyone have the same issue?

[PGSmick]

I have a Dropbox Plus account going pretty far back--I have a \Public folder off the root.  I'm not sure what's happened with the Public folder, but I can no longer do what I have in the past.    That is, I regularly upload photos to a sub-folder of Public and I used to be able to generate a dropbox link for a photo similar to the following: https://www.dropbox.com/s/xchd31aqqbfizn8/HEIModuleBracket2.JPG?dl=0

I would then create a post on my favorite website (an old PHP-Nuke board) where I am a member (with no control over what happens there), and I could enter that link in a post.  To be sure, I needed to modify the link slightly to get it to work.  The modified link was:  https://dl.dropbox.com/s/xchd31aqqbfizn8/HEIModuleBracket2.JPG

 When that link was surrounded by [img]...[/img] tags, the photo would show up in the post for any viewer with or without a dropbox account.

Now, when I upload a photo to dropbox and get a link for it, the link looks like this: https://www.dropbox.com/scl/fi/crv0udpyha55r26fvjsnk/PistonWear.png?rlkey=j9dgg2fgpiiwqy5v2ck4awn4s&...

and I cannot figure out how to edit this link so that it displays in a post on the website.

I am also finding that some of my previously posted photos still generate the simpler URL (without the rlkey parameter), but some of them generate the URL with the rlkey parameter, and I can't predict which I'll get until I try it.

So can someone please explain what is happening here?  And, how do I either a) reliably generate an older style URL, or b) modify the newer style URL to work with my website's [img]...[/img] techology?  

This feels like a security or permissions issue, but I'm not sure.  If this post belongs in another section, would someone please redirect me.

Many thanks,

Peter