We’re Still Here to Help (Even Over the Holidays!) - find out more here.
Forum Discussion
Best way to authorize more users on my app
Hi all, my scenario is as follows: 1) mobile app 2) app server for redirect uri I need to allow users to access their dropbox space from my application. So each user will have to authorize his co...
Greg-DB
Dropbox Community Moderator
Dropbox Community ModeratorCan you elaborate on what you mean when you "the response that the dropbox server sends to my server has no information about the user"?
You can find information on how the result is returned to the redirect URI in the OAuth 2 /authorize documentation here:
https://www.dropbox.com/developers/documentation/http/documentation#oauth2-authorize
Note that there are two "flows": the "code" flow and the "token" flow. It sounds like you may be using the "token" flow, where the result is returned on the URL "hash" or "fragment". Browsers intentionally don't send this information to the server; it is only available client-side. For server-side redirect URIs, you should use the "code" flow instead. For the "code" flow, the result is returned in URL parameters, which are sent to the server.
Hi Greg,
thanks for the reply,
Yes, I am using flow code. As documented, the dropbox server replies by sending me the code (ex: Nhiajajoiqpqi912alalala). In my project the request_uri is the application that runs on the server and not the mobile app (it must always be available for callback). But I can not connect this code to one of my users, because I do not know which of my users has made the dropbox authorization request from the mobile app, and that code is related only to a user who made the request. I do not know if my problem is clear.
- Greg-DB
When using the "code" flow, Dropbox will return an "authorization code" to your redirect URI. This authorization code is specific to the Dropbox user that authorized the app. You should then exchange this authorization code for an access token using /oauth2/token. In addition to the access token, that endpoint will return the account_id of the Dropbox user that authorized it. (Additionally, you can check the account information for an access token by using it to call /2/users/get_current_account.)
While that identifies which Dropbox account was used, it doesn't identify the account in your third party app itself. Typically, you would get this from your app's own session. (I.e., whoever is signed in to your web site or app.)
If, for whatever reason though, that doesn't work in your use case, you can pass along other identifying data in the "state" parameter to /oauth2/authorize, which will be passed back by the /oauth2/authorize result to your redirect URI.
Yes Greg,
I use this solution.
Greg-DB ha scritto:When using the "code" flow, Dropbox will return an "authorization code" to your redirect URI. This authorization code is specific to the Dropbox user that authorized the app. You should then exchange this authorization code for an access token using /oauth2/token. In addition to the access token, that endpoint will return the account_id of the Dropbox user that authorized it. (Additionally, you can check the account information for an access token by using it to call /2/users/get_current_account.)
While that identifies which Dropbox account was used, it doesn't identify the account in your third party app itself. Typically, you would get this from your app's own session. (I.e., whoever is signed in to your web site or app.)
in this case I do not have the security that the user who requested the authorization has used the same data (mail, name etc.) in the registration to my service, so the comparison between accessID and myUserID can be done but it does not work at 100%. Do you Agree with me?
Greg-DB ha scritto:If, for whatever reason though, that doesn't work in your use case, you can pass along other identifying data in the "state" parameter to /oauth2/authorize, which will be passed back by the /oauth2/authorize result to your redirect URI.
I tried to pass a userid on "state" but as described here:
state String? Up to 500 bytes of arbitrary data that will be passed back to your redirect URI. This parameter should be used to protect against cross-site request forgery (CSRF). See Sections 4.4.1.8 and 4.4.2.5 of the OAuth 2.0 threat model spec.
this field is used for protect against cross-site, infact in the callback from dropbox to my server the field state is filled correctly but I don't have the code because it is hidden. does it happen to you too?
thank a lot
- Greg-DB
I'm not sure I follow. What do you mean by "accessID"?
Also, can you clarify what you mean when you say " field state is filled correctly but I don't have the code because it is hidden"?
Please note that I'm happy to help with any questions or issues you have with the Dropbox API itself, but I can't offer general security guidance. If you have any app security questions, please consult with a security professional.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
