409 error with (JS SDK).sharingGetSharedLinkFile(), works with curl or browser

[blobwriter]

I think there's another thread from a couple of years ago about this on the forum, but the forum search didn't bring it up, so here we are..

As described in the title - I have a shared link to a file, which works when I just follow $shared_link_file_url in the browser (whether logged in or with incognito mode), or if I use:

curl -L ${shared_link_file_url}

In both cases, the contents of the text file are returned.

If instead, I use the JS SDK in the browser to call dropbox_instance.sharingGetSharedLinkFile({ url: $shared_link_file_url }), I get a 409 "shared_link_access_denied" error, even if logged in. 

So....bug? Timeline on a fix?

[Greg-DB]

Can you confirm you're using an API app registered with the "app folder" access type? There is a bug that results in this error when using this method with an access token for an app folder app. That's still open with engineering, but I don't have a timeline on a fix.

[blobwriter]

Yep, that's exactly correct, thanks for the fill-in.

So with global Dropbox  access scope it doesn't happen? That's a much higher trust barrier to get over for users, unfortunately.

And just to check: I don't think there's an auth flow for users to make that decision (regarding access scope) for themselves, right? Can an app request global scope, be rebuffed and given only AppFolder scope, and then have to figure out for itself what it should do (e.g. regarding paths)? That way if a user only allowed AppFolder scope, I could just notify them that sharing won't work for the time being.

But as it stands currently, [global scope] vs [app folder scope] is solely set from the DevConsole, is that correct?

Anyway, regarding the root issue of broken shared links in AppFolders, as a temporary workaround it would be pretty sweet if someone at Dropbox could turn on the Access-Control-Allow-Origin header for publicly shared links, so a regular JS fetch() call could suffice. Or maybe set up a temporary CORS proxy, so I don't have to pay to run one myself? Pwetty pweeze? 😛

[Greg-DB]

Yes, this bug only affects apps with the "app folder" type, not the "full Dropbox" type.

And that's correct, the "app folder" versus "full Dropbox" type is selected when first registering the API app. There isn't a way to dynamically set or fall back on that, e.g., during the authorization flow. You could register one of each however and switch between them as needed though.

Anyway, I can't make any promises on a workaround, but I'll pass it along.