Steve M. Dropboxer

You can't. I would generally recommend keeping a mapping in your own database of file IDs to whatever custom metadata you want. It might help if you explain your scenario a bit more.

That looks like a "preview" link, which is a link to an HTML page. If you instead use the "direct" link type, you'll get a link directly to the file.

That's the Chooser, and it's invoked client-side via JavaScript. See https://www.dropbox.com/developers/chooser for the documentation.

"Utah J.", I was trying to help Brynn get help for what seems like a product bug that's causing him a problem. I understand that the path field of an individual call to /metadata doesn't provide you the current casing of the full path. (You can of course walk back up the path and reconstruct the full casing if you need to,…

Brynn, I don't think your post relates to the API, so it doesn't belong here. That said, Dropbox is case-insensitive but case-preserving. In the case you describe, I don't think case-insensitivity is a problem, but the lack of case preservation is. If the zip file was one generated by Dropbox, then this sounds like a…

Interesting. So I guess Navigated fires too late? But you tried Navigating as well, right? It seems like that should certainly fire before JavaScript on the page is executed.

"The fragment is not removed by Dropbox." /redirect_receiver has JavaScript on it that removes the fragment after the page is loaded. The reason I'm asking about other redirect URIs is because they won't have that behavior.

Have you tried DocumentCompleted or maybe Navigating? Also, have you tried using a different redirect URI, like https://www.example.org? I'm just curious if this relates to the JS on the page removing the fragment or if it's somehow an inherent issue with the event you're listening for.

Nekobul, can you share your code for how you're getting the URI in your Navigated event handler?

"why Dropbox does the redirect with fragment and not the regular query (?) tag when doing the token flow?" That's how OAuth 2 works. As to why OAuth 2 works that way, it's to prevent the token from being sent to the server. The query string is part of the URL that's sent to the server, while the fragment is not. The…

Please let us know what you learn about the Windows 7 issue. Again, it can't really be the fault of Dropbox itself, but maybe there's a bug in the WebBrowser control? (Or maybe there's some *expected* reason why the WebBrowser control is supposed to launch an external browser, but that would be surprising.)

For #1, I have no idea what's happening, but I can't see how it would be a Dropbox issue. It certainly doesn't happen in the code I shared earlier, so it also doesn't seem to be an issue with the WebBrowser control under its default settings. For #2, I had a little trouble following what happens under what circumstances,…

Ah! I can reproduce this too, but only when the user is authorizing an app they've already authorized (so they skip the screen asking them to "allow" access). I don't understand why this makes a difference as to whether the DocumentCompleted event is fired, but it seems to. (You can try this yourself by revoking your app's…

I'm unable to reproduce this on Windows 10. I created a new Windows Forms app, added a web browser control to it, and wrote the following code. I saw a message for loading (among others), the redirect_receiver page, complete with an access token. Perhaps you can try this stripped-down version of the code and see if it…

We'll try to reproduce this. Could you tell us what version of Windows you're running on? (I assume Windows 10?)

Could you share your code? Also, have you seen https://blogs.dropbox.com/developers/2014/04/dropbox-authorization-in-a-windows-forms-app/. The code there, at least at the time I wrote it, worked. (But note that there I never tried a localhost URL.)

The Dropbox API supports both OAuth 1 and OAuth 2. The generated access token is a OAuth 2 token, but the SDK you're using only supports OAuth 1. OAuth 1 tokens are different and have two components: a token and a token secret. You won't be able to use a generated access token with the iOS Core SDK.

Just pass the path you want instead of string.Empty. E.g. dbx.Files.ListFolderAsync("/myfolder").

Cross-linking with Stack Overflow: http://stackoverflow.com/questions/35387312/error-in-call-to-api-function-users-get-current-account-unexpected-url-params/35388273.

You need a slash at the beginning of the path.

I tried these steps in Edge on my Windows 10 computer which shows an identical user agent, and everything worked as expected. Perhaps it's something specific to your local setup? Have you tested on other computers?

A bit of extra detail: The documentation for /thumbnails is here: https://www.dropbox.com/developers-v1/core/docs#thumbnails. The default format returned is JPEG, but you can also ask for a PNG. The documentation for /previews is here: https://www.dropbox.com/developers-v1/core/docs#previews. That endpoint always returns…

Just for future debugging, "Bad Request" is the status line. The actual body of the response should contain an error message that probably said something about a missing parameter. :-)

What's the body of the 400 response?

In that SDK, the method is called http://dropbox.github.io/dropbox-sdk-dotnet/html/M_Dropbox_Api_Files_Routes_FilesRoutes_DeleteAsync_1.htm.

Which SDK? Via the HTTP API, it's /files/delete. Search for "delete" here: https://www.dropbox.com/developers-preview/documentation/http#documentation.

I'm not sure what you mean... could you share the code you're using to download the file? I believe you can choose whatever local path you want?

The code for the iOS SDK is part of the downloadable zip file. I assume you can just add the code directly and compile however you're compiling the rest of your app. Is that not true?

Cross-linking with Stack Overflow: http://stackoverflow.com/questions/34043932/how-can-i-access-the-associated-values-of-swiftydropbox-errors.

No, those links always expire after 4 hours.