Steve M. Dropboxer

If I understand you correctly, you're no longer getting an "unauthorized access" error at all. Is that right? If so, please explain the new issue you're seeing. Include the relevant code, what you expected to happen, and what actually happened.

The signature that you originally posted looks broken... it should have an ampersand (&) at the end of it. (When URL-encoded, and ampersand ends up being a %26.) See https://blogs.dropbox.com/developers/2012/07/using-oauth-1-0-with-the-plaintext-signature-method/ for an example.

I edited your post to remove the signature, but you may want to get a new app key and secret now that yours has been published here.

I searched for little bits of that code, and I'm pretty sure that code comes from this project: https://code.google.com/p/oauth/. Is that right? Are you using that library? Have you asked the owners of that library for help? It does look like that library supports PLAINTEXT signatures, so I still recommend switching to…

We're getting closer. :-) It looks like the actual signature is created via oAuth.GenerateSignature. Is that code you wrote or a library you're using? Could you share that code?

The bug is presumably in GenerateSignature, but I don't see that code. Is that something you wrote, or is it from a library you're using? If at all possible, I'd recommend switching to OAuth 2, or at least https://blogs.dropbox.com/developers/2012/07/using-oauth-1-0-with-the-plaintext-signature-method/. Both are simpler…

My guess would be that the library you're using makes request with OAuth 1 with an HMAC signature, and the signing code has a bug relating to URL encoding. Does the error happen for all files that have parentheses in it? Can you tell us what library you're using? (Ideally, give us a link to it.)

Okay, thanks. The team will continue investigating whether it makes sense to just support \*/\* in the future.

Do you happen to have any links handy to where people are using "file/*"? I'm trying to figure out how common it is. We may simply be able to support "*/*", which is what it appears Google Drive does.

I wasn't aware of the convention around using "file/*", but I'll pass this along to the team. If that's the recommendation on Android, I imagine we can add support in a future version of the app.

The Android app doesn't support the MIME type file/*, but we do support these ones: * application/* * audio/* * image/* * text/* * video/* * multipart/*

It looks like you're sending https://en.wikipedia.org/wiki/MIME#Form-Data, which explains the extra data you're sending. You should instead be sending the raw bytes of the file as the body of the HTTP request. From a quick search, I think ByteArrayEntity is what you want (instead of MultipartEntity).

My guess would be an encoding bug on your side. (Perhaps you're treating the data as text instead of binary?) Can you share your code?

Assuming your app has "App folder" permissions and uses the app folder name gegham, then its root is /Apps/gegham, so your paths should be relative to that. Just use the path /magnus-opus.txt: file_share = client.share('/magnus-opus.txt', short_url=True)

Dropbox doesn't have a permission model that looks like that. In Dropbox, you can create a share link for a file or folder (which can then be used by anyone who has that URL to read the contents of the file or folder), or you can share a folder (which gives specific users access to that folder in their own Dropbox).…

I believe you'll need to wrap the call in a try/catch so you can handle the exception when the path doesn't exist. For your second question, this isn't possible in the API today. (The email addresses of members of a shared folder are not exposed.)

https://www.dropbox.com/developers/core/docs#restore is the right endpoint. When you say it "did not seem to work," what do you mean? What did you try, and what exactly went wrong?

"Steve: thanks for the tip, from which I presume there's no capacity in the SDK to upload large files." I'm not sure that you mean. That's precisely what those methods I linked to are for.

He's talking about http://dropbox.github.io/dropbox-sdk-dotnet/html/M_Dropbox_Api_Files_Routes_FilesRoutes_UploadSessionStartAsync.htm, http://dropbox.github.io/dropbox-sdk-dotnet/html/M_Dropbox_Api_Files_Routes_FilesRoutes_UploadSessionAppendAsync_1.htm, and…

If you're asking about whether you can control the "selective sync" feature of the Dropbox desktop client programmatically, the answer is no. We don't provide an API to control the behavior of the desktop client.

Just try it and look for a 401 response to indicate an auth problem. I might use the /account/info endpoint for this (since it pretty much can't fail for any other reason). But note that the access token could be revoked at any time, so you'll still need to handle the case where the call you're actually making fails. E.g.,…

Take a look at https://blogs.dropbox.com/developers/2013/12/writing-a-file-with-the-dropbox-javascript-sdk/ and see if that helps. You'll need to use OAuth to authenticate the user. (The sample code in that blog post takes care of that.)

I suspect that the error is that your path doesn't start with a slash. In API v2, paths should either be empty, meaning the root of the user's Dropbox, or they should start with a slash. So try using "/test" as the value of folder. As to why you don't see the exception, my C# async/await knowledge is somewhat limited.…

I expect us to support Python 3 in the new API v2 SDK. (Note that the current preview SDK doesn't support Python 3 yet.)

Thanks for doing this!

This SDK uses delegates, so the expected way to write code is to call loadFile and then continue with the next step in loadedFile. If you take a look at our https://blogs.dropbox.com/developers/2015/05/try-out-swiftydropbox-the-new-swift-sdk-for-dropbox-api-v2/, you'll see that we're moving towards using blocks in the…

Just put your code to read the file in your implementation of loadedFile.

Mitchel, your issue doesn't seem related to the one in this thread. Please start a new thread.

Also, have you implemented the uploadedFile and uploadFileFailedWithError delegates as described in https://www.dropbox.com/developers/core/start/ios#uploading? If the error delegate is called, you should be able to see exactly what failed.

If I try to GET http://sejda.com/path/to/file.pdf, I get redirected to https://sejda.com/path/to/file, so I imagine that's why HTTP isn't working either. (It's just being redirected to HTTPS and then failing.) As to the underlying cause, on my computer, I get the same SSL cert when using curl. When I use the latest version…