Child Item

iOS 17.x can no longer login and allow dropbox access on app

i, something has changed with iOS 17. My app is using the DropboxClient() api to get an auth token, which would show safari and ask for a login.

The login works, and they will get the question if they want to allow my app access. When they click on Allow, they now get the error:

Safari can't open the page because it couldn't connect to the server.

I was using the redirect uri of "http://localhost/authorize"

private const string RedirectUri = "http://localhost/authorize";
var authorizeUri = DropboxOAuth2Helper.GetAuthorizeUri(OAuthResponseType.Code, appKey, RedirectUri, state: state, tokenAccessType: TokenAccessType.Offline);

This was working fine until iOS 17 came out.

Does anyone know how to fix this? It appears that iOS 17 no longer allows safari to connect to localhost?

I am using c# (xamarin/maui) for iOS.

Find more posts tagged with

API

Abuse

Comments

Greg-DB

It looks like this is more about iOS and its interaction with local servers/Xamarin, as opposed to the Dropbox API itself. You may be better served by referring to resources about iOS or Xamarin for help with this.

For instance, I found this thread which may be helpful.

phunction

It appears HttpListener is the issue, is there another way to use Dropbox in my app? Or to at least authorize the app, because it does work fine on iOS 17 if the app has already been authorized/logged in with iOS 16

Здравко

Some workaround (till real solution finding out) could be copying auth code by hands instead of using HttpListener for that. 🤷 Somehow ugly, but will work stable everywhere. 😉

Good luck.

Greg-DB

@phunction As Здравко said, you can omit the redirect URI entirely, in which case the user will be presented with the authorization code directly so they can manually copy/paste it into the app.

Otherwise, to use a redirect URI if you can't use a server, you can use a redirect URI with a custom URL scheme for your app, if you use PKCE in the app authorization flow. A redirect URI with a custom URL scheme would look something like "customappscheme://auth"; you would need to decide on and set the exact strings you want to use and configure that for your app. Refer to your platform's documentation for information on defining and using custom schemes like that.

phunction

I was looking at the example for PKCE, but it still uses httplistener, which I think is the issue. What is the best way to make this work in iOS 17.x? Has the .Net API been tested with iOS 17.x yet?

Greg-DB

The Dropbox .NET SDK examples happen to use a listener, but the authorization flow itself also supports custom URL schemes when using PKCE.

In any case, the Dropbox .NET SDK is not built for or tested with Xamarin/Maui/iOS in particular. I'll pass this along as a feature request for official support for that, but I can't promise if or when that might be implemented.

Note that, separate from the .NET SDK, Dropbox does offer native SDKs for Swift and for Objective-C meant for use on Apple platforms. Dropbox recommends using these native SDKs for those platforms, as they'll handle most of the work of the authorization flow for you.

phunction

OK, thanks. Is there an example currently on line that shows the "customappscheme://auth"; method with PKCE?

Greg-DB

I don't believe we have a full example for that exactly, but I have a post here that may be helpful.

phunction

I am trying to get this work with my iOS app, I have an redirect uri of myapp://oauth2redirect

However, I am unable to use it as my dropbox account wants me to use a uri of https:

What am I missing here? How do I get pkce to work without having to have some kind of webserver setup?

When I try to start the authflow, the dropbox website gives me the error:

Error 400: Invalid redirect uri. It must exactly match one of the redirect uris you've preconfigured for your app (including the path).

I use

var authorizeUrl = DropboxOAuth2Helper.GetAuthorizeUri(OAuthResponseType.Code, appKey, pkceuri, state: state, tokenAccessType: TokenAccessType.Offline, codeChallenge: codeChallenge);

Greg-DB

@phunction The particular error message you shared here is referring to the redirect URI not being registered for the app; it isn't referring to the protocol (such as "https://" or "myapp://").

Whether using PKCE or not, the redirect URI value (the "pkceuri" variable in your code) must exactly match one of the redirect URIs registered for the app (based on the app key being used, the "appKey" variable in your code) on the App Console. If the redirect URI does not match exactly, you'll get that error message. To fix that, sign in to the account that owns the app (if you're not already) and register the relevant redirect URI using the "OAuth 2" "Redirect URIs" section of the app's page on the App Console.

It may be helpful to print out the values of "appKey" and "pkceuri" to double check you're registering the exact redirect URI for the relevant app.

phunction

I have my pkce redirect setup at mytestapp://oauth2redirect

I entered that into the app console (I was mistaken that the uri had to have https:)

When I send the request, I now get the page asking if I want to authorize the app, when I say ok, it just gives me a string to enter into my app, it does not appear to automatically redirect.

Does this work when debugging?

I am not sure how the redirect works, when the browser opens and you authorize, does the browser now send back a message to iOS with the redirect URI, and iOS should see that the app has registered that uri in the info.plist then pass the returned info to the app?

Greg-DB

The redirect URI functionality works the same way regardless of whether you're debugging or if your app is in development or production status.

If the authorization page is showing the authorization code to the user on the authorization page (with a message like "Enter this code into ... to finish the process") then that means that a redirect URI wasn't used. If that's not what you intended, make sure you're still setting a redirect URI when building the authorization URI.

And yes, when using a redirect URI, after the user authorizes the app, Dropbox will redirect the user's browser to the specified redirect URI with the authorization code included. When using a custom URI scheme (like "myapp://" or "mytestapp://" in your examples), the browser and operating system handle that redirect to send it to the right place. For example, as you said, iOS would see which app has that particular scheme registered and would send that redirect to that app.

phunction

Turns out I has an extra space in my auth uri.

I have it working now, thanks for all the help.