App is stuck on slow internet

[sundeepkmallick]

Checklist:

• [x ] I am using the latest release
• [x ] I searched for existing GitHub issues
• [ x] I read the documentation
• [x ] I verified the client configuration matches the information in the identity provider (or I am using dynamic client registration)
• [x ] I am either using a custom URI scheme or https with App Links for client redirect.
• [x ] I can reproduce the issue in the demo app (optional)

Configuration

• Version: 0.10.0
• Integration: native Java
• Identity provider: KeyCloack

Issue Description

App is getting stuck when internet is slow as reported by end users. To cross verify I set the mobile network to 2G and could able to reproduce. It stuck at https://<redirect_uri>?state=<>&session_state=<>&code=<>. If I set the mobile network to 4G then redirection back to app is happening seamlessly. Is it possible to fix this problem or can there be any indication from library to users about the slow internet? Now users are complaining that the problem is in mobile app and not with their internet because they could able to reach to Login screen on website and able to provide credential and post successful login on website, they could see another screen where they could tap on Authorize/Proceed button. And after that only, problem is happening where they get stuck. Ofcourse the duration of loading of login screen and further screen are slower but not stopping users to proceed. There is no handshake issue because everything works flawlessly on same and multiple devices with good internet connection. Please help me here.

[agologan]

If it gets stuck at the redirect it's not an issue with the connection but with the way the integration works (or in this case doesn't).
If that is the correct redirect to your app then it should get resolved locally on the device and not impede the user.
If the user is seeing a blank page with the redirect instead of getting back to your app, then the issue may be somewhere else.

[sundeepkmallick]

Hey @agologan, hope you are doing good and nice to converse after long time. It came to my surprise during the testing after user reported. I tried with 2G internet to reproduce. Three/Four times it was stuck on browser after redirection. On fourth time it got redirected. And with 4G on same device at almost similar time, app was not stuck and works nice. Is there anyway to from the library to indicate user that his internet is slow?

I can create another ticket if you prefer for below query as it is different topic than this bug ticket:

In the mean time another user also reported that he's too seeing blank screen. After having live session I found that he is using Samsung device and Samsung Internet browser was set to default. He could able to see Login Screen, Logs In and then tap on Proceed button and then stuck. I asked him to change his default browser to Chrome, he did not get stuck. After reading through #157, I have the doubt now not all browsers support fully either OAuth 2.0 or OpenID or custom tabs. So my questions are:

1. Is there any way to find out if the default browser doesn't support OAuth 2.0 and OpenID and custom tabs OR alternatively not let the user to open the first URL (authorization_endpoint_uri) itself if not compatible. I set my default browser to Bing and added below code, but it did not restrict to go to Bing:

BrowserMatcher blacklist = new VersionedBrowserMatcher( Browsers.SBrowser.PACKAGE_NAME, Browsers.SBrowser.SIGNATURE_SET, true, // custom tab VersionRange.ANY_VERSION); builder.setBrowserMatcher(blacklist);

2. There's a method configureBrowserSelector() where we can choose a browser for testing, but is there any way to restrict the user not to open the browser which does not have custom tabs using any library code?

I can identify if the default browser has custom tabs which Android code inside my app. But if the library already has some mechanism, I would prefer to utilize that.

[agologan]

The issue is not with Custom Tabs or OAuth2.0/OIDC support but with support for App Links.
Not all browsers implement App Links or honour them correctly, so when you redirecting back via an http redirect you can get stuck quite often if you're not using a supported browser.

As a library maintainer we do not plan to maintain a list of supported browsers and we leave it up to the developers to figure the right parameters for their own app.

In contrast custom URIs have much better support overall and can be a better solution when you can control the IdP configuration.

Regarding browser matcher's to restrict you should check you are targeting the right app by looking at https://github.com/openid/AppAuth-Android/blob/master/library/java/net/openid/appauth/browser/Browsers.java#L132 or creating your own matcher.