Handling multiple Redirect url in Android

[davideravasi]

Good morning, I consider this an issue since is supported in the original AppAuth implementation and apparently not supported in the Flutter Plugin. I tried to look into documentation and available resources online but this feature seems not supported. Basically, to handle a deep link in Flutter/Android with this library I need to place in the gradle file the following instruction:

manifestPlaceholders += [
                'appAuthRedirectScheme': 'test.myapp.com'
        ]

The point is, what if, like in my case, I have an app that works in multiple environments and some of them are redirecting the token exchange result to something like 'dev.myapp.com' and some of them to 'prod.myapp.com'?

Usually, what you do natively, is placing 2 intent-filters over an activity. But apparently with this Flutter Library there are no ways to do it. Even the manifest (another place where handling it) is mentioned just in relation to a problem with Android 11 and newer OS versions, not for this scope.

Here you find the link to AppAuth implementation where seems possible handling the intent in the manifest (and more of them): https://github.com/openid/AppAuth-Android/blob/27b62d5da94023941db545b70036a742a52b7070/README.md#capturing-the-authorization-redirect

I would like to know:

• If is possible and is just not mentioned in the documentation
• Or if not and there are no ways to implement it even with a workaround

Thank you!

[MaikuB]

The steps covered in the docs is to cover the common setup most apps would go through. I've yet to try what you mentioned but this plugin uses the same SDK underneath. Furthermore, the intent filter configuration isn't specific to a plugin, it's a generic step for configuring deep-linking on Android in general (see https://developer.android.com/training/app-links/deep-linking). With those points in mind, if you're saying it works when using the AppAuth Android SDK directly or when building an Android app the "traditional" way, then I don't see why it wouldn't work and would be something you should be able try out to confirm

[davideravasi]

Hello @MaikuB "then I don't see why it wouldn't work and would be something you should be able try out to confirm" > yeah that's the reason why I opened the issue. I mean, I've tried but I don't know how much flexibility I have in trying solutions where your implementation requires something different.

I tried first of all these 2 options:

1. manifestPlaceholders += [ 'appAuthRedirectScheme': 'test.myapp.com', 'com.myapp.com ]
2. manifestPlaceholders += [ 'appAuthRedirectScheme': 'test.myapp.com', 'appAuthRedirectScheme': 'com.myapp.com', ]

In both, does not work... (because I assume is a key/value, not an array) Then, in your documentation you mention that, if I target the latest version of Android I have to add this to my android manifest:

<queries>
        <intent>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="https" />
        </intent>
        <intent>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.APP_BROWSER" />
            <data android:scheme="https" />
        </intent>
</queries>

Here I might try but honestly if from your documentation you expect the variable in the gradle file to fulfil the redirection makes no sense trying there.

So, a new specific question might be: does your implementation expect a variable (appAuthRedirectScheme) in the gradle file to work? If yes, and it's not an array, I don't see any way to achieve with your implementation.

NOTE: Please check the image attached in this comment. I took this screenshot from the AppAuth original documentation. As you can see is mentioned an ALTERNATIVE for the gradle variable, does it work for your implementation as well?

[MaikuB]

There's seems to be misunderstanding here that you think the things documented are to do with this plugin's implementation but that isn't actually true. All of the things in the readme are actually based on what the AppAuth SDK needed. They're not really to do with what this plugin needs. The manifest change too was a requirement from Android itself (see https://medium.com/androiddevelopers/package-visibility-in-android-11-cc857f221cd9) and was a step that use to be in the readme for the AppAuth Android SDK. Presumably it's no longer there as the plugin has baked the change in directly but even if you add it in that causes no harm.

So to repeat, what is supported comes down to what they native SDK supports so if you want to know if the something it documents works or not then this something you're better off verifying directly as it's not a question of if "my implementation" supports it