Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check here.
Forum Discussion
Solved
Is there a way with java API to get an event when access token is refreshed
Hello, I'm maintaining a Java Desktop application that can use Dropbox to store user data. I've just discovered that my Dropbox integration doesn't work anymore for new users because of the API ...
After implementation, the solution is not to subclass DbxClientV2. Indeed, the refreshAccessToken method is not called when the client refreshes the token.
On the other hand, we can pass a subclass of DbxCredential to the constructor of DbxClientV2. DbxCredential's public refresh method is called by the client when the token needs to be refreshed. Then, we can intercept the result of the refresh and do what we want with it.Here is an example:
public class ObservableDbxCredential extends DbxCredential {
...
@Override
public DbxRefreshResult refresh(DbxRequestConfig requestConfig, DbxHost host, Collection<String> scope) throws DbxException {
final DbxRefreshResult refresh = super.refresh(requestConfig, host, scope);
// Insert your code to save the new access token here;
return refresh;
}
}
Fathzer wrote:...
I've just realized that there's no new refresh token emitted when access token is refreshed. I also read that Dropbox refresh tokens never expires!
... It feels like the refresh token is the new long-lived token 😊
Hi again Fathzer,
Yes, that's the idea. 🙂 And it's not just feels, it is actually.
Fathzer wrote:...
So my question is a little bit silly.
I can simply store the refresh token once and reuse it "forever" to create a DbxCredential with a dummy access token already expired. This dummy access token will be automatically refreshed during the first call. ...
No, you question is not a silly one. It depends what you're trying to achieve. Yes, you can just store the refresh token and use it forever (even more it's mandatory for long term access).
For project that imply application running for long time and Dropbox client object stay along application work, such a way, described by you, is the best choice because there cannot take too much effect of optimization (it's negligible). It's another story if you are preparing command line tools or dynamic plugin for some application. In such cases one client object initialization can become related to only one or few API calls, so removal of every meaningless API call (the one fired to refresh the access token) gonna reflect significantly on application/plugin performance. Many objects may need to be build consecutively again and again in relatively short period if time! But that's a detail that depends on the project you are working on...
Hope this sheds additional light.
After implementation, the solution is not to subclass DbxClientV2. Indeed, the refreshAccessToken method is not called when the client refreshes the token.
On the other hand, we can pass a subclass of DbxCredential to the constructor of DbxClientV2. DbxCredential's public refresh method is called by the client when the token needs to be refreshed. Then, we can intercept the result of the refresh and do what we want with it.
Here is an example:
public class ObservableDbxCredential extends DbxCredential {
...
@Override
public DbxRefreshResult refresh(DbxRequestConfig requestConfig, DbxHost host, Collection<String> scope) throws DbxException {
final DbxRefreshResult refresh = super.refresh(requestConfig, host, scope);
// Insert your code to save the new access token here;
return refresh;
}
}
About Discuss Dropbox Developer & API
Make connections with other developers
