You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to integrate the AppAuth authorization flow by replacing the default browser tab with a custom activity that handles login (& 2FA). The service configuration has two links:
I've declared a working AppLink bound to the "authorization endpoint" inside the manifest but the authIntent created by the library contains a package specification that permits only to the selected app to open the intent.
The method that creates the intent is this, in particular, line 565:
intent.setPackage(mBrowser.packageName);
effectively disallowing AppLinks to work.
I'm not sure if the reason behind the implementation was relative to security or ease of use but the RFC 8252 has a section (7.2) which state:
[...] When the browser encounters a claimed URI, instead of the page being loaded in the browser, the native app is launched with the URI supplied as a launch parameter. [...]
Thus, it should not be against rules.
In the end, for now, I've found a dirty solution that changes the intent's content:
binding.button.setOnClickListener {
val service =AuthorizationService(this, advancedConfiguration)
val intent = service.getAuthorizationRequestIntent(authorizationRequest)
//
intent.extras?.apply {
val i = getParcelable<Intent>(KEY_AUTH_INTENT) ?:return@apply
i.setPackage(null)
putParcelable(KEY_AUTH_INTENT, i)
}
//
resultLauncher.launch(intent)
}
And I'm working at the LoginActivity to correctly integrate the flow (ex. by starting an intent to simulate the last redirect to the RedirectUriReceiverActivity).
Thanks in advice,
Davide.
The text was updated successfully, but these errors were encountered:
Think you're on the right track, though you may be interested in this proposed change #622
While I did find the proposal good, I never spend the time to properly review it and integrate it.
Your feedback on that PR would be appreciated, and if it works as expected maybe I can set aside some time and integrate it.
Android contains an intent attribute named "autoVerify" that does exactly what the PR adds.
I do not know if reimplementing the mechanism is the right thing to do. If the PR's author (@fabian-hk) can help us, it would be appreciated.
I propose to integrate what the android developer site suggests.
from the link above:
Android App Links verification
When android:autoVerify="true" is present in at least one of your app's intent filters, installing your app on a device that runs Android 6.0 (API level 23) or higher causes the system to automatically verify the hosts associated with the URLs in your app's intent filters.
Please, anyone able to improve my consideration or correct it should speak!
Configuration
Description
I'm trying to integrate the AppAuth authorization flow by replacing the default browser tab with a custom activity that handles login (& 2FA). The service configuration has two links:
I've declared a working AppLink bound to the "authorization endpoint" inside the manifest but the
authIntent
created by the library contains a package specification that permits only to the selected app to open the intent.The method that creates the intent is this, in particular, line 565:
effectively disallowing AppLinks to work.
I'm not sure if the reason behind the implementation was relative to security or ease of use but the RFC 8252 has a section (7.2) which state:
Thus, it should not be against rules.
In the end, for now, I've found a dirty solution that changes the intent's content:
And I'm working at the
LoginActivity
to correctly integrate the flow (ex. by starting an intent to simulate the last redirect to the RedirectUriReceiverActivity).Thanks in advice,
Davide.
The text was updated successfully, but these errors were encountered: