About Greg K.

By default, Dropbox API access tokens for your app(s) don't expire by themselves, but there a number of different ways that a Dropbox API access token can become invalid: the user can revoke all access tokens for an app by unlinking it on the connected apps page any client with the access token can revoke the access token by calling /2/auth/token/revoke if the app uses the "app folder" permission, the token can be disabled by the user deleting the app folder itself in the Dropbox account, either via the Dropbox website or any client the app can be disabled the account that owns the app can be disabled the connected account can be disabled Also, I should note that the Dropbox API was designed with the intention that each end-user would link their own Dropbox account, in order to interact with their own files, in which case they would only have access to their own access token(s). It is technically possible to connect to just one account, by always using a specific access token, for all end-users of your app, and it sounds like that's what you're doing in this case. Please be aware that we don't recommend doing so, for various technical and security reasons. This is especially true for client-side apps, such as Android apps, as they can't keep the access token a secret from the end-users. ... View more

@namiqismayil No, I don't have any updates on this. Dropbox hasn't changed the officially supported environments for the Chooser. I can't speak to what may have changed in Outlook itself though. ... View more

@Ashu7878 The domain is the same for all users from all countries. I just can't promise that it won't change in the future. In general though, there isn't a way to verify the source of the link since it is shared locally in JavaScript in the client, and the client can't be trusted (since it is under the control of the user, who may or may not be malicious). If you have any general web security questions, I recommend reaching out to a security professional.  ... View more

@Ashu7878 Right now, the direct links returned by the Dropbox Chooser are always on dl.dropboxusercontent.com, but that isn't officially documented or guaranteed, so I can't promise that won't change.  I'll pass this along as a request to officially document/guarantee that, but I can't say if or when that might be done. ... View more

@buttflattery Yes, when the API returns an async job like this, you'll need to use the relevant endpoint to periodically check the status of the job until it's done. The Dropbox API doesn't offer webhook functionality for this, or any other way to be automatically notified of async job status changes, but I'll pass this along as a feature request. I can't promise if or when that might be implemented though.  ... View more

Thanks for trying that and letting me know. I'm glad to hear that cleared up that exception. There are other ways for uploads like this to fail, so it may not still be a certificate issue. The file would be committed by the `UploadSessionFinishAsync` method. What does that method return for you now? Or, does code execution even reach there? I recommend adding some logging and/or stepping through with a debugger to see what's happening, since you don't currently seem to be checking the return value for the upload session calls. Anyway, I'd also try adding back each of the `InitializeCertPinning` and the custom HTTP client individually to see which one is causing the issue (if it is just one of them). If it's just the custom client, you may still be able to use `InitializeCertPinning`. Otherwise, I can't offer much guidance on how to configuring Unity to pin the certificate. You can find the certificate information and code here though, in case it helps. In any case, the Dropbox API servers aren't self-signed, and the certificate pinning isn't strictly necessary. All Dropbox API calls require TLS, and the pinning would just be an additional security measure. ... View more

[ Cross-linking for reference: https://stackoverflow.com/questions/58399992/unity-netcore-dropbox-api-2-0-throwing-argumentoutofrangeexception-on-async-d ] I'm afraid we probably can't offer much support on this particular issue, as we don't officially support Unity, and the error appears to be occurring deeper in the stack, outside of Dropbox code anyway. It looks like this exception is occurring during the TLS connection with content.dropboxapi.com, inside Mono.Unity.UnityTlsContext.ProcessHandshake. The reference to 'TrustFailure' would seem to indicate an issue with the certificate verification, but the Dropbox API content servers are being served with a valid certificate though.  The top exception seems to be a generic index exception anyway though, so it may just be a bug in ProcessHandshake. I'd try eliminating the use of `InitializeCertPinning`, as well as the use of the custom `HttpClient` (the SDK will use a default one if you don't supply one). ... View more

Thanks for the report! For reference, sending non-ASCII characters in HTTP headers is not officially supported, so please make sure you're encoding any non-ASCII characters in headers as documented here: https://www.dropbox.com/developers/reference/json-encoding There was a change on our server stack last week that affected how we handled HTTP headers without proper encoding. That resulted in malformed file paths/names like what you've described. We've reverted that change, so that should be working again, but please make sure your headers get encoded properly. As for the duplicated copies, I can't say off hand what may be causing that, but it might be due to some bad state left over in the app or account from when that change was live. If you can reproduce that now, please share the following so we can investigate: the name and version number of the platform and SDK/library you are using, if any the steps to reproduce the issue, including relevant code snippet(s) the full text of any error or unexpected output ... View more