It seems that we cannot programmatically change those uris at runtime, since, the intent filter for RedirectUriReceiverActivity or manifestPlaceholders = [
'appAuthRedirectScheme': ''
] has fixed values.
So theoretically with this library we cannot have a app with a settings/preference panel where we can change, let's say the redirect uri and have the app running(building it once). For all possible redirect uri's we have to prefil the <data android:scheme=''> ?
Is that so ?
If so then why this design decision was taken ? (I can think of custom tab implemented within an activity and scenarios similar to overriding onRedirectUrl of Webview being used to similar end)
Further with this intent forwarding model, if the user is already logged in the browser, calling Authorization request with same credential (redirected to Callback url) doesn't get intercepted by RedirectUriReceiverActivity
You can't change intent filters are runtime in Android, this isn't a decision specific to AppAuth. The manifest placeholder value is there mostly for convenience in defining a custom scheme based redirect capture, you can completely override this by providing your own manifest entry for RedirectUriReceiverActivity with a tools:node="replace" property, like this:
<activity
android:name="net.openid.appauth.RedirectUriReceiverActivity"
android:exported="true"
tools:node="replace">
<!-- whatever filters, properties etc you want for this definition -->
</activity>
What you describe with a settings panel where you change the redirect URI dynamically is not possible - the URIs must always be registered in the manifest at compile time.
I assumed as much :( .
I'm struggling why -
If the user is already logged in the browser, calling Authorization request with same credential (redirected to Callback url) doesn't get intercepted by RedirectUriReceiverActivity ?
e.g., User signed into Chrome Browser with web Outlook (and didn't sign out),
Now an app using Microsoft OAuth tries to login via custom tabs as implemented here in this library, the RedirectUriReceiverActivity is not called and the page is stuck on chrome custom tabs view. On inspection of the url I can see that the url is the same as that set as redirect url in the library.
Cannot figure out why ? (On cleaning chrome browser creds the app works fine again !)
Is the redirect occuring after a user click? If the redirect is automatic (i.e. triggered by Javascript), then Chrome will not send an intent to a registered app - an explicit user action is required. There are two ways we know of to deal with this:
If the IDP supports the OpenID "prompt" parameter, pass this with value "consent" to force display of a consent screen.
Create a web page for your redirect URI that displays "Welcome back, $USER - Click _here_ to return to the app". Upon click, do the real redirect to the app's custom scheme. My other demo does this to deal with GitHub, which does automatic redirect.
@iainmcgin sorry to take up your time, I couldn't find what the relevant portion for what you did for the second option "Create a web page for your redirect URI that displays "Welcome back, $USER" in your pointed repo. Is it pointed to point me to a started point in the code.
In the demo config for GitHub, it uses this redirect URI, which if you look at the source for that page, does roughly what I described: creates a custom scheme link on a button, copying all the query parameters.
ohh, I was looking for a custom page you created
Thanks !!!
AppAuth redirection from chrome browser to application not working. However if we add firefox to browser whitelist by removing chrome it works perfectly fine. With firefox browser the redirection perfectly works fine. Chrome app version is 79.0.3945.136
Most helpful comment
Is the redirect occuring after a user click? If the redirect is automatic (i.e. triggered by Javascript), then Chrome will not send an intent to a registered app - an explicit user action is required. There are two ways we know of to deal with this:
If the IDP supports the OpenID "prompt" parameter, pass this with value "consent" to force display of a consent screen.
Create a web page for your redirect URI that displays "Welcome back, $USER - Click _here_ to return to the app". Upon click, do the real redirect to the app's custom scheme. My other demo does this to deal with GitHub, which does automatic redirect.