Child Item

Switching users in app

Hi All

is it possible (in a test app) to login as user 1, view files etc, then log out and log in as user 2, view their files etc?

My app is using an OAuth2 flow in .net, its a windows forms app.

during the authentication routine, it opens a browser window and presents the login page. the access token is then kept to validate operations.

when logging out, i remove the access token (set to string.empty), in addition - ive also sent a TokenRevokeAsync request. after awaiting that event it loads up the login browser and immediately restores the previous access token.

Im using the Developer API for .net (official)

the method on the login form(browser) that is called, is:

        Public Sub Start(ByVal appKey As String)
            Me.oauth2State = Guid.NewGuid().ToString("N")
            Dim authorizeUri = DropboxOAuth2Helper.GetAuthorizeUri(OAuthResponseType.Token, appKey, New Uri(RedirectUri), oauth2State, False, False)
            Me.Browser.Navigate(authorizeUri)
        End Sub

then:

      Private Sub BrowserNavigating(ByVal sender As Object, ByVal e As NavigatingCancelEventArgs)
            If (Not e.Uri.ToString().StartsWith(RedirectUri, StringComparison.OrdinalIgnoreCase)) Then
                ' we need to ignore all navigation that isn't to the redirect uri.
                Return
            End If

            Try
                    Dim Result As OAuth2Response = DropboxOAuth2Helper.ParseTokenFragment(e.Uri)
                If (Result.State <> Me.oauth2State) Then
                    Return
                End If
                Me.AccessToken = Result.AccessToken
                    Me.Uid = Result.Uid
                    Me.Result = True
                Catch eww As ArgumentException
                    ' There was an error in the URI passed to ParseTokenFragment
                Finally
                    e.Cancel = True
                    newAttempt = False
                    Me.Browser.Navigate("about:blank") ' nav away
                    Me.Hide()
                End Try
        End Sub

Could anyone suggest anything to make this work?

BTW: on first run, there is no credential stored so i know this is something to do with cached credentials.

Find more posts tagged with

API

Abuse

Comments

Greg-DB

You can certainly switch users by switching access tokens, as you're attempting to do. It sounds like the issue is that when you direct the user to authorize the app a second time, they're being automatically redirected back to your app, along with a (new) access token for that same account.

This can happen if the user is still logged in to the Dropbox web site and has already authorized the API app.

If instead you want to avoid this behavior and make sure the user has a chance to switch accounts, you can set the forceReapprove parameter to true on DropboxOAuth2Helper.GetAuthorizeUri:

https://dropbox.github.io/dropbox-sdk-dotnet/html/M_Dropbox_Api_DropboxOAuth2Helper_GetAuthorizeUri.htm

knight2601

Hi, I've tried that, it just auths them in to that same account but asks for permission to connect to their dropbox.

i've tried deleting local cookies, creating new browser controls (incase it was an IE caching issue) to no avail.

It's being cached in the app/api somewhere, if i close the app and reload it, its clean and prompts for login with no token, does the API cache the last key and return it instead of a new auth run?

Andy

Greg-DB

You didn't mention where/when you actually switched accounts. Did you do so? When using forceReapprove=true, you would need to manually (as the user on the Web site) switch the account you're logged in to by logging out and then logging in as the other account, before authorizing the app again.

knight2601

The app is a Windows desktop app (wpf), process:

Load test app
Select user - if credentials (token) doesnt exist for that user already (in app storage) - then the app directs user to a browser control to auth with dropbox.
at this time the user can retrieve lists, download, upload etc..
switch accounts in the app, (if credentials (token) exists in the app for that user, then dropbox will list/operate on the correct user account).

(the first time it auths in dropbox - it's fine) 2nd login auth attempt: If the credentials don't exist then user is directed to auth in dropbox, but dropbox immediately returns the authorize token from the previous user, if force is on in the connection - then dropbox shows the previous user info and asks for connection to their dropbox account.

the logout method i have - just clears the accesstoken, in the app, for the logged in user. I've tried calling the relevant endpoint to invalidate the token, but thats the wrong usage of that procedure as a new access token isnt required, just the most recent user logged in.

so it looks like either:

the app is caching the response? I've tried removing the application cookies (using Windows.Application.SetCookie method, I've destroyed the browser and using XAMLwriter - created a new browser control in the form, deleted all relevant cookies from the cookie folder in windows (contains 'www.dropbox.com' & '__Host-js_csrf').
dropbox api endpoint is caching the response?

So just to be clear: Its the second login to dropbox browser auth routine that is returning the 1st token, not the second.

Maybe i need to do something to notify dropbox of the user logging out?

Any ideas?

Andy

Greg-DB

Can you share a sample project showing the issue? That should help us see exactly where the problem is happening. Thanks in advance!

nairababayan

I have the same problem described above.
Is there any solution for this issue?

Thanks,
Naira Babayan

Greg-DB

@nairababayan It looks like the author of this thread stopped responding, but I suspect what you're seeing is due to the automatic redirect behavior of the Dropbox OAuth 2 app authorizatin flow.

From my response earlier:

If instead you want to avoid this behavior and make sure the user has a chance to switch accounts, you can set the forceReapprove parameter to true on DropboxOAuth2Helper.GetAuthorizeUri:

https://dropbox.github.io/dropbox-sdk-dotnet/html/M_Dropbox_Api_DropboxOAuth2Helper_GetAuthorizeUri....

Note that the user will still need to manually log out and back in to the desired account on the Dropbox web site itself though, when they're presented with the choice to authorize the app.

If that doesn't seem to be the issue in your case, please open a new thread with the details of your particular problem so we can help you individually without spamming anyone else on this thread:

https://www.dropboxforum.com/t5/forums/postpage/board-id/101000014

Thanks!

xtremebytes

@Greg-DB

@Greg-DB wrote:

If instead you want to avoid this behavior and make sure the user has a chance to switch accounts, you can set the forceReapprove parameter to true on DropboxOAuth2Helper.GetAuthorizeUri:

https://dropbox.github.io/dropbox-sdk-dotnet/html/M_Dropbox_Api_DropboxOAuth2Helper_GetAuthorizeUri....

Note that the user will still need to manually log out and back in to the desired account on the Dropbox web site itself though, when they're presented with the choice to authorize the app.

This thread is now quite old but isn't better to set

forceReauthentication = true

in the API call so that the app presents the login screen and a different user has the chance to login? Semantically, forceReapprove only asks the user to re-approve the app's Dropbox access permissions.

Greg-DB

@xtremebytes It depends on the use case, so it's up to the developer to decide what makes sense for their app. The newer `forceReauthentication` can be more inconvenient than `forceReapprove` though, since the user is forcibly signed out and has to sign in again. With `forceReapprove`, the user can still choose to switch accounts if they want/need. That being the case, I would generally recommend `forceReapprove` over `forceReauthentication`.

xtremebytes

@Grek K. thanks, I see your point about inconvenience. I am probably looking at it from a use-case where the user wants to disable the Dropbox integration and be presented with a user login screen when re-enabled again because it is likely to be disabled with the intent to switch users. There is a slight chance that the user may accidentally overlook the small sign-out link on the re-approval page, and still re-approve as the previously signed-in user. So, perhaps, it does make more sense in my app to set 'forceReauthentication'.