So i tried following this article about obtaining my perm app token. I did the exact steps. but it always gives me a different Token when i try to access the linkhttps://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/Tokens-only-valid-for-4-hours-from-app-console/td-p/425269am I doing something wrong here? it feels very confusing.
If you are referring to processing the OAuth app authorization flow, note that each time you do so, you will get a different access token (and refresh token, if you're requesting one). These values are expected to be different each time. You only need to process this flow when needed though. For instance, if you are requesting "offline" access, and so are receiving a refresh token, you should store and re-use the resulting refresh token, without processing the app authorization flow again.
If you haven't already, I recommend reading the following resources for more information on this:
If something isn't working as expected or if you're still stuck on something, please show us what the problem is and we'll be happy to help however possible.
Hey there, this still isn't really working. the problem is the call for token just always expires so I cannot be able to get the code running for longer than 4 hours. please help
Dropbox is switching to issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens, so this is expected. You can find more information on this migration here. That being the case, you will get a short-lived access token by default. (You can identify a short-lived access token by the "sl." prefix.)
Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention. You can find more information in the OAuth Guide and authorization documentation.
While the change to only issue short-lived access tokens began on September 30th, we're releasing it gradually, so you may not have seen your app(s) affected until now. Once it applies to your app, it would apply regardless of the "Access token expiration" setting for your app, and that setting may no longer be available for your app.
Note that if you are not the programmer responsible for this integration, you may need to get an update from them to support this.
So is it no way other than that to get a perm token? I don't think offline mode work and I need the old way to function. I think that's the only thing stopping the code to work now which is a perm token that does not expire after 4 hours
As the title says, I am trying to generate a refresh token, and then I would like to use the refresh token to get short lived Access tokens.
There is a problem though, in that I'm not smart enough to understand the docs on the dropbox site, and all the other information I've found hasn't worked for me (A, B, C) or is in a language I don't understand.
I have tried out all three examples from the github page, as well as user code from other questions on this site.
I haven't got anything to work.
The most I got was
Error: 400 Client Error: Bad Request for url: api.dropboxapi.com/oauth2/token
and
dropbox.rest.RESTSocketError: Error connecting to "api.dropbox.com": [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1123)
To clarify, are you the programmer or an end-user of the app in question? If you are not the programmer of the app, you'll need to reach out to them for help.
For reference, the "offline" flow itself works, but it is something that would need to be implemented by the programmer of the app. In any case, the creation of new long-lived access tokens is being phased out and so may not be available for any given app.
I'm not the programmer, and the programmer is struggling to understand the dropbox document so i'm sort of asking on behalf of him. the above question was raised by the developer so I'm simply dropped it here.
Thanks for clarifying. In that case, please have the developer contact us directly if they need help implementing this. The specifics will depend on their existing code, platform, language, etc. They can contact us privately here if they prefer.
Please these is urgent, I need non expiration tokens... this change its a delay...if i don't have non expirations tokens, i should change to other server like google drive... please change it again... think about it
The decision you have made about making changes on your platform is a delay. It functioned way more better before these changes were made.
-------------------------------------------
Thanks for the feedback! I'll share this with the team.
Could clarification be added to the app console itself that the token is short-lived? I spent around 20 min to finally land on this thread and realize we no longer have the option to generate long lived access tokens, would help prevent redundant additional threads on this topic 😅
Thanks for all the info Greg!
@sanchitcop19 Thanks for the note! I'll ask the team to clarify this in the UI there.
Thank you!
Unfortunately, we have the same problem with the token, which is only valid for 4 hours.In a backup plugin for the iot system iobroker we use the API for backup in the Dropbox.
Unfortunately, the token expires after 4 hours, which unfortunately means that users do not have a backup in the Dropbox.
We have about 45,000 users of the plugin and people are having really big problems with changing the token lifetime
Here is the link to the project
https://github.com/simatec/ioBroker.backitup
@simatec Thanks for the note. You'll need to update your app to use refresh tokens if it needs to maintain long-term access without manual user intervention. You can find more information on this migration here, and you can find more information about this functionality in the OAuth Guide and authorization documentation.
Unfortunately, the variant of the refresh_token cannot be implemented for our plugin.
For your understanding...us backup plugin doesn't have its own app.Users who want to save their backups in Dropbox create an app in their account.
In order for the user to receive a refresh_token, in-depth knowledge is required, which not all users have.
With the switch to the short_live token, I would like the Dropbox API to continue to be usable. With a validity of 4 hours, this is not the case to use it for a backup system.
iobroker is an iot system that usually runs on linux machines without a GUI and without a browser.
This also means that no authorization query is possible.
Would it be possible to display the refresh_token in the APP console?
In this way, we could offer the option of updating via the refresh token in our backup tool.
But users should get the refresh_token in an easy way
The current way is not user friendly
@simatec1976 Thanks for the information. I'm sending this along as a feature request for the ability to get a refresh token via the Generate button on the App Console, but I can't promise if or when that might be implemented.
For reference, we do not recommend having end-users create/register apps themselves on Dropbox and then use the Generate button like this. The developer of the app/plugin/integration should register it once, and then implement the OAuth app authorization in the app/plugin/integration so that the end-users can authorize it to access their accounts without having to configure it themselves. That would apply to both the previous long-lived access token functionality, as well as the new short-lived access token and refresh token functionality. Previously, the user would need to process the OAuth app authorization flow once to get the long-lived access token. Now, they would do the same, and the app gets a short-lived access token and refresh token the same way, instead of a long-lived access token. The process would look the same to the end-user in both cases. The app would store and re-use the long-lived access token, or the refresh token, respectively.
@simatec Whether using the old long-lived access tokens, or new short-lived access tokens/refresh tokens, 'redirect_uri' is optional when you're using 'response_type=code' (such as for the standard code flow for server-side apps, or PKCE flow for client-side apps). When it is omitted, the user is presented with the authorization code directly on the Dropbox web site after authorizing the app, which they would then copy/paste into the third party app for it to complete the flow, that is, calling /oauth2/token to get the resulting access token/refresh token.
Thank you for your explanations. I integrated the authorization into our GUI and submitted the APP for production due to around 45,000 users of our plugin. How long does this test normally take? I currently have many users with problems and the support effort is currently very high. I hope that the app will be released for production soon so that users can use it normally again. The app is called: Backup-DropCloud Thanks in advance.
@simatec1976 That should be processed within a few business days. If you need help with a production request you can always open a ticket via https://www.dropbox.com/developers/contact .
@Greg-DB
My request was denied because the app name doesn't match the plugin name.
Unfortunately, this name is already taken and I can't do anything about it
@simatec1976 I just checked on this, and it looks like you already have an open support ticket for that, so they'll follow up with you there soon.
thx for your support.Yes, I opened a ticket or replied to the rejection by email.Unfortunately, the app can only be checked if you install the iot system iobroker.
That means there is no website or access to test it.The whole thing is integrated in the plugin backitup for the iobroker.
I've come a long way now.
However, I'm hanging on refresh_token with PKCE.
How can I do a refresh with the VERIFICATION_CODE.
I didn't want to work with client_secret.
with client_secret the example looks like this:
curl https://api.dropbox.com/oauth2/token \ -d grant_type=refresh_token \ -d refresh_token=<REFRESH_TOKEN> \ -u <APP_KEY>:<APP_SECRET>
Is there also a way to refresh_token with the VERIFICATION_CODE instead of the client_secret?
I really don't want the client_secet in the Source code
Hey @simatec1976
To use the /oauth2/token with a refresh token that was retrieved via the PKCE flow to get a new short-lived access token without using the app secret would look like this:
curl https://api.dropbox.com/oauth2/token \ -d refresh_token=<REFRESH_TOKEN> \ -d grant_type=refresh_token \ -d client_id=<APP_KEY>