Hello, I'm using Swifty dropbox and wanted to know the difference between accountId I get from getAccountId() call vs. the userId set in my shared client.
Thanks in advance!
These are just different formats for identifying Dropbox accounts. Is it causing any problems in your app?
I'm trying to figure out which one to use to uniquely identify a user in a consumer app. Are they both globally unique? Which one makes more sense for me to use for this purpose?
They're both globally unique, but the longer one from getAccountId is preferred in general, and is required when interacting with the API v2 calls themselves, e.g., when specifying a user.
Is there a way to get UID in Java API ?
I have been using the UID as a user identifier in my APP ...
I have been able to access this in Swify and .NET
RTS, API v2 only uses the new account ID format, so we recommend moving to that if you're using API v2. You can use the getAccount method to get account information, including the account ID, from API v2 in the Java SDK. You can continue using API v1 methods if necessary though.
My app has been around since before V2 ... I already have UID in the database.
I have already converted OSX, IOS to V2, developed the .NET APP.
All of those have access to UID.
Now you are recommending that I stay on V1 for android ?
Is this a long term stable identifier ?
API v1 isn't deprecated, so you can use it if you want, but we certainly recommend moving to API v2 when possible.
For API v2, you should use the account ID, which is stable. As part of migrating to API v2, you should get the account IDs. I.e., for any access token, call the getAccount method to get the corresponding account ID.
OK, but I hope this is stable for V3 ....
user identification is critical for resource not maintained entirely on your server.
I have been inserted the UID in the Database for unique purpose. It is an integer value. As i will integrate the V2 what i will do.
For Example:
V1
User A : uid:123456
get the data from datatbase like as
Select * from User where uid=123456 - Is working fine.
V2
User A : dbid:asd3-asdf ds
Only coming the dbid is not there uid. How to migrate. Already 1000 user have uid. How to change dbid.
Please give solution.
Arusnundar, you can call /2/users/get_current_account for any given account using the account's access token and store the new account_id value from there.
Gregory,
I have already stored the user id (UID integer) in the Database. But I didn't get UID instead of DBID. You told correct, i will stored the account_id. Even I need the UID to get for old user account info.
My Questions is,
Please give a solution.
1. No, API v2 doesn't return the v1 user ID.
2. For each user you have, with a known user ID and access token, use that user's access token to call /2/users/get_current_account and store the resulting account ID as being for that user.
Poking this thread back into life, is there a way in V2 to get the V1 userId?
I have no problems changing to use the accountID going forward, but it would be very helpful if there were a way to get the V1 userID (read-only) for those who have thousands of existing installs that use the Dropbox V1 userID as a primary key. As things stand there's no way to associate existing users with their data.
Another problem I'm running into with the removal of the userID is that the URL to a file revision history is using this userID. These URLs are in the following format: https://www.dropbox.com/history/[PATH_TO_FILE]?_subject_uid=111111111. Is there another way to generate them now that API v2 no longer returns the userID?
We are finishing up our API migration, and hit a bit of a snag here. The solution for mapping old account IDs (uid) to new account IDs (account_id) seems to be a proactive call to the V2 API with an existing token to retrieving account_id. Is this correct?
Does this mean that we need to get every user (we have tens of thousands) to use our app in some way so we can piggyback a call to get account_id before the V1 api is shut off? If a user takes a hiatus from our app and then tries to use it after the V1 API shutoff, there would be no way to associate the IDs at that point, correct?
I don't suppose there is a way for you folks to add uid to the get_current_account return?
Barring that, is there a better way to do this to prevent some users being caught on the outside of the transition?
Will existing tokens remain valid after the V1 shutoff?
"The solution for mapping old account IDs (uid) to new account IDs (account_id) seems to be a proactive call to the V2 API with an existing token to retrieving account_id. Is this correct?"
That's correct, you should call /2/users/get_current_account with the existing access token to get the account_id.
"Does this mean that we need to get every user (we have tens of thousands) to use our app in some way so we can piggyback a call to get account_id before the V1 api is shut off? If a user takes a hiatus from our app and then tries to use it after the V1 API shutoff, there would be no way to associate the IDs at that point, correct?"
You don't technically need to do this before API v1 is retired. Also, you don't really need to wait for users to be active to make this API call. As long as you have the access token, e.g., for a server-side app, you can just make the API call whenever you'd like. (For a client-side app, yes, you'd have to have them run the app, since you presumably don't have the access token anywhere except on the client.)
"I don't suppose there is a way for you folks to add uid to the get_current_account return?"
I've sent this along as a feature request, but I don't have any news on that.
"Barring that, is there a better way to do this to prevent some users being caught on the outside of the transition?"
I do recommend just going through all of the existing access tokens to get and record the account_id.
"Will existing tokens remain valid after the V1 shutoff?"
Access tokens aren't being deactivated. In fact, if you have OAuth 2 access tokens, you can use those directly on API v2. (One exception there is if your app happens to use the "file type" permission, which isn't supported by API v2.) If you have OAuth 1 access tokens, you can migrate them to OAuth 2 using API v2's /2/auth/token/from_oauth1.
I just realized that DropboxOAuth2Flow still returns both UID and DBID. Can we count on this call staying as is?
http://dropbox-sdk-python.readthedocs.io/en/latest/moduledoc.html?highlight=DropboxOAuth2Flow#dropbox.oauth.OAuth2FlowResult
