Child Item

Dropbox custom URL scheme

I am developing an expo app. It needs to redirect back to the app after users have given authentication. When I was using expo go for basic testing this seemed to work fine but now that I am testing a development build and eventually a production build my process does not seem to work. I can navigate to dropbox.com/oauth2/authorize but returning to the app after receiving permission from the user seems to be the issue.

In my app.json file I have:

"expo": {

"scheme": "myapp",

}

Here is how I build my redirect URI:

import * as AuthSession from 'expo-auth-session';

export function StartupAutheticationScreen() {

const dropboxRedirURI = AuthSession.makeRedirectUri({path: 'Auth'});

...

}

The authentication process works until i give permission. Once I click 'allow' I am not redirected to my app. Any help would be greatly appreciated. Thanks!

Find more posts tagged with

API

Abuse

Comments

Здравко

Hi @squidlauncher64,

You're providing too few info for what actually you're going to do. Why at all you need special scheme for your application? In general Dropbox API supports only HTTPS scheme as redirect URI and HTTP if the host is 'localhost' only. On mobile devices are supported also 'db-<APP KEY>' schemes. As far as I know no other custom schemes are possible! Anyway, for web applications usually the classical web protocol is enough. 🤔 Or not?

squidlauncher64

Thank you for replying! This is for an application for mobile devices. I would prefer to be directly routed back to the phone app to handle the access tokens. I guess I could reroute to a website domain I just think it would be cleaner this way. Dropbox did successfully reroute me to the 'expo go' app after authentication and I know that redirect URI was something along the lines of exp://127.0.0.1:19000. The problem is returning back to the app in development and production builds once authentication has completed.

Здравко

@squidlauncher64 wrote:
... This is for an application for mobile devices. I would prefer to be directly routed back to the phone app to handle the access tokens. ...

Yes, you can do it. That's exactly what 'db-<APP KEY>' scheme is for (where <APP KEY> is your application's key). Your application should be ready to handle redirect URI like 'db-<APP KEY>://1/connect'. And URL to start from is a bit different (https://www.dropbox.com/1/connect).

Good luck.

squidlauncher64

Thank you for your response. I have attempted using 'db-<APP KEY>' with my actual app key and I am still not redirected to the mobile app. The allow button is greyed out. Do you have any other ideas?

Greg-DB

@squidlauncher64 It is possible to use a custom URI scheme with the Dropbox OAuth app authorization flow, using the code flow with PKCE. For example, I just tried this out with an authorization URL like this:

https://www.dropbox.com/oauth2/authorize?client_id=APPKEYHERE&response_type=code&redirect_uri=customscheme://redirect&code_challenge=CODECHALLENGEVALUEHERE&code_challenge_method=plain

Dropbox did then return the redirect to the "customscheme://redirect" redirect URI, as you can see in this screenshot:

Screenshot 2023-11-16 at 9.58.11 AM.png

I don't actually have an installed app registered for the "customscheme://" scheme though, so my browser accordingly reported the NS_ERROR_UNKNOWN_PROTOCOL error for that network request, and the "Allow" button is left disabled.

It sounds like that's what's happening in your case; Dropbox is attempting to perform the redirect requested, but your system was unable to process that URL scheme for whatever reason.

Exactly how you register your custom URL scheme will depend on your platform, but that's outside the scope of Dropbox API support so I can't offer insight on that. You may need to refer to the documentation or support resources for your platform for information on how to set that up.

Здравко

@squidlauncher64 wrote:
... I have attempted using 'db-<APP KEY>' with my actual app key and I am still not redirected to the mobile app. ...

Hm...🤔 I just tried it out too:

изображение.png

... and finally as a result (after hitting Allow) I got:

изображение.png

Here oauth_token_secret is authentication code actually (the one masked in green).

If you got something different, post screenshots of the exact steps.

Greg-DB

Please note that the /1/connect page is only meant for use by the official Dropbox SDK(s) and is not documented or intended for third party implementations. When implementing the OAuth app authorization yourself, please use /oauth2/authorize, documented here, e.g., as shown in my previous message.

Здравко

@Greg-DB wrote:
Please note that the /1/connect page ... is not documented or intended for third party implementations. ...

Hm...🤔 Really? In such a case what's something not "intended for third party implementations" doing inside official Dropbox SDK (public accessible and documented) that's intended for third party implementations? 🧐 Isn't strange enough? 😁

Greg-DB

@Здравко To clarify, that is meant for the implementation in the official Dropbox SDK(s), and third parties can certainly use the official Dropbox SDKs, but third parties are not meant to re-implement the functionality using /1/connect themselves.

squidlauncher64

Ah ok I am using the api itself not the dropbox sdk. I should have clarified that. Sorry about the confusion. I am a novice at this. Here is a screenshot of what happens before i push the accept button:

Untitled 2.png

squidlauncher64

After I push the button it greys out the accept button:

squidlauncher64

Thank you for all your help!

Здравко

Doesn't matter whether you use SDK or not. Your screenshots just show that for some reason your schema is not able to activate any installed handler (including, but not only your application). Unfortunately, your screenshots don't carry too much information for details. In general different reasons can be, but may be set in 2 groups. First, your application may not be installed correctly as particular scheme handler. This is easier to check. Just put in your browser address line a URI that matches your application expectations (including the scheme). Does, after hitting enter key, your application get up in front of the browser? If Yes, the check is passed successfully, but if no you have some configuration mistake in the application and have to fix it. Second, redirect URI that comes from Dropbox after confirmation may not match to your idea. To see what comes there, an easy way is to copy your browser address line before hitting 'Allow' and paste in desktop browser address line. Usually there are tools letting you trace what's going on. In network tab you can see the redirect request (code 302,after hitting Allow) and find out What's in the 'location' response header. Does it match your (application') expectations, including schema? If Yes, it's Ok, but if no, you have mistake in URL, related to launching the linking process, construction (more careful focusing on the details may be needed).

Hope this gives direction.

squidlauncher64

So it fails the first check. Here are the guides i have been trying to follow:

https://docs.expo.dev/guides/linking/#linking-to-your-app

https://docs.expo.dev/guides/linking/

According to the documentation all I need is to put a scheme in the app.json file which I have done:

Here is a snippet from the app.json:

"expo": {

"scheme": "myapp",

}

Then I use this in my authtnetication script:

Here is how I build my redirect URI:

import * as AuthSession from 'expo-auth-session';

export function StartupAutheticationScreen() {

const dropboxRedirURI = AuthSession.makeRedirectUri({path: 'Auth'});

console.log(dropboxRedurURI)

The console.log outptus "myapp://Auth", Is there something I am missing? Thanks again for all your help?

Здравко

@squidlauncher64 wrote:
So it fails the first check. ...

In such case your application cannot be launched and that's why your browser "freezes". At that moment the browser does exactly what you did - tries open the same URI - unsuccessfully. To be honest, I'm not familiar with your environment and cannot say what exactly is wrong or if is what you say enough. The only fact is that, as seems (according your words), the application is NOT registered as a handler properly. You have to check and fix whatever needed. The only thing I would advise is to check if all parameters are available in end package (for example, in Android manifest have to be registered an activity with appropriate intent filter, that matches your scheme). That would be a good start point, for instance. 😉

Good luck.