[Question] Redirect from browser after web auth doesn't happen

[egorshulga]

Version: 1.2.2

Steps to reproduce:

1. Call auth.webAuth.authorize().
   Browser with a hosted login page opens.
2. Perform authentication.

Expected behavior:
The browser redirects execution back to the application.

Actual behavior:
Redirect doesn't happen.
I have to press back button to return to the application.

logcat output:

02-06 17:54:41.260   563  1451 I ActivityManager: START u0 {act=android.intent.action.VIEW dat={URL_WITH_TOKEN} cmp=com.univer.mobileui/.MainActivity (has extras)} from uid 10178 on display 0
02-06 17:54:41.374   563 15525 W InputMethodManagerService: Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy@8cb3b23 attribute=null, token = android.os.BinderProxy@78f7b8f

This behavior was introduced by PR #126.
Downgrading to the version 1.2.1 resolves the issue.

[egorshulga]

cc @lbalmaceda, @cocojoe

[egorshulga]

Now I use patch-package to revert changes of #126.

[lbalmaceda]

Which browser app is causing this, and which android version?

[egorshulga]

Android 7.1.2, both Firefox and Chrome have the same behavior.

[egorshulga]

In my view, the current behavior is expected. The browser activity which is launched in the current task fires a redirect, this redirect is captured by the intent filter of my application. But the application is already on top of the stack with a browser activity in the foreground. So I have to navigate back to the activity of my application by pressing Back button.

What were the reasons of PR #126, which made the browser activity to run in the task of the app?
Is it possible for the intent filter to replace browser activity with the app activity on top of the stack?

[egorshulga]

Besides, FLAG_ACTIVITY_NO_HISTORY is apparently required.
Docs: If set, the new activity is not kept in the history stack. As soon as the user navigates away from it, the activity is finished. This may also be set with the noHistory attribute.
The browser activity indeed should not be kept in the history.

[cocojoe]

@egorshulga Hi, I suggest you look at the original issue #124 to look at the change in behaviour. However, this change alone does not introduce the issue you are reporting. I have tested this in API25 with Chrome and @lbalmaceda has tested with Chrome and Firefox with no issues.

I feel this is most likely a configuration issue as we are unable to reproduce your issue using our standard sample project.
If you can checkout https://github.com/auth0-samples/auth0-react-native-sample and recreate your issue there and then provide the steps to reproduce then we can look at it. A video/animated gif would also be good.

[egorshulga]

Ok, I cloned auth0-react-native-sample repo, updated all dependencies to latest versions:

  "dependencies": {
    "react": "16.2.0",
    "react-native": "^0.53.0",
    "react-native-auth0": "^1.2.2"
  },
  "devDependencies": {
    "babel-jest": "22.2.0",
    "babel-preset-react-native": "4.0.0",
    "jest": "22.2.0",
    "react-test-renderer": "16.2.0"
  },

Then I copied my credentials into auth0-credentials.js file.
Then I run the example app both on real phone (android v7.1.1) and emulator (android v8.1.0).
The gif is recorded on the emulator, but I have the same behavior on the phone.

You can see that the loader indicator is shown infinitely and I explicitly press the Back button.

[egorshulga]

Ok, I also had to replace android:host property in AndroidManifest.xml cause chrome in adb logcat showed Navigation is unreachable error message.

Unfortunately for me, I cannot reproduce the issue so I have to recheck my entire configuration.

[egorshulga]

Well, I'm stuck.
I understand that is a issue with my configurations but I have no idea where should I dig in.
Could you give me any clue where to search for errors?

[cocojoe]

@egorshulga Sure, it would probably be a good to take 5 mins, create a clean project and work through the Quickstart, in particular the Android steps. Also check against the README

It is often something small like the launch mode or an activity.

[Msspl-PrashenjeetRoy]

I am also facing the same issue just like @egorshulga posted earlier, but In Android, it's working & in iOS, the issue is coming. Just showing an indicator. @cocojoe

[stefanedberg]

I'm having the same problem on Android. Working on iOS. Downgrading to version 1.2.1 resolves the issue.

"react": "16.3.1",
"react-native": "0.55.3",
"react-native-navigation": "^1.1.444",

compileSdkVersion 27
buildToolsVersion "27.0.3"

android:launchMode="singleTask"

[lbalmaceda]

@stefanedberg Probably related to react-native-navigation. Check my comment on a similar issue.

[JanErikFoss]

Same problem on android, iOS works fine.
I'm not using react-native-navigation.

[JanErikFoss]

Changing android:host to my custom auth0 domain fixed the issue.

I would advise anyone who doesn't have a custom domain to at least double check that their host is correct.

[jbuck94]

@JanErikFoss can you provide an example of what changing the host looks like? not sure exactly what/where to update?

[JanErikFoss]

@JanErikFoss can you provide an example of what changing the host looks like? not sure exactly what/where to update?

In your AndroidManifest.xml you should have something that looks like this.
You need to double check that the android:host string is correct.
In my case I had to use my custom domain (login.bikefinder.com) instead of my default auth0 domain (bikefinder.auth0.com).

<!-- react-native-auth0 webAuth -->
<intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data
        android:host="login.bikefinder.com"
        android:pathPrefix="/android/${applicationId}/callback"
        android:scheme="${applicationId}" />
</intent-filter>

[lbalmaceda]

Changes introduced in the PR #126 are OK. And Android 9 is now enforcing the use of that flag when starting activities from a context other than an Activity (the one used for the Custom Tabs scenario). This is not an issue of the SDK. I'll proceed to close this one, but don't hesitate in opening a new one if you run into other kind of issues with this SDK.

Regarding the use of custom domains as @JanErikFoss correctly pointed out you need to update the host. That behavior is explained on the feature page where the use of SDKs is mentioned. The way the authentication works on native clients is that after you've logged-in in the browser, you get redirected to the app. For that to succeed the redirect uri sent on the web authentication must match whatever you have registered in the intent-filter of your android application. If there's a subtle different, things won't work. (You'll get stuck on the browser app).

• On the README you are asked to update the android manifest: https://github.com/auth0/react-native-auth0#android
• Then to whitelist a redirect uri in your dashboard: https://github.com/auth0/react-native-auth0#callback-urls
• Finally, you will need to initialize the SDK with the client id and domain values. https://github.com/auth0/react-native-auth0#usage.

If any of these 3 steps above declare a different domain, the redirection will fail.

There's only one that would remain using the "auth0 domain" instead of the "custom domain", and that is the userinfo or /api/v2/ audience parameter, if you are passing them here https://github.com/auth0/react-native-auth0#log-in. As explained in the custom domain docs.

[M1chaelChen]

Setting launchMode to singleTask inside AndroidManifest.xml fixed for me. It is mentioned in the doc but a bit hard to notice.

[cenergon]

Hello egorshulga, I'am the same problem. did you solve it? thank!

[leemcmullen]

@cenergon Hey, I've seen this behaviour caused when the applicationId has a mix of upper and lower case characters e.g. com.MyAppName.dev.

So let's say you have the following intent filter

  <intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data
      android:host="@string/Auth0Host"
      android:pathPrefix="/android/${applicationId}/callback"
      android:scheme="${applicationId}" />
  </intent-filter>

When .authorize() is called, it generates a redirect_uri which it then passes into the authentication browser. This tells the auth screen where it should redirect to when auth is successful. When it builds this uri, it converts the applicationId to lowercase for the scheme part. It allows this to happen even if your configured "Allowed Callback URLs" (in the Auth0 console) contains the scheme portion with the original casing (com.MyAppName.dev).

However the uri it'll actually be trying to redirect back to once you've authenticated will be com.myappname.dev. That obviously doesn't match your config and so the browser just hangs and you're not redirected.

It's mentioned here to use lowercase for the scheme: https://developer.android.com/guide/topics/manifest/data-element

It's a slightly tricky one to track down because Auth0 doesn't seem to validate the scheme part for casing although it does validate the pathPrefix part.

[lbalmaceda]

We mention the use of lowercase for Android apps in the readme. But.. there's always room for improvement, what will be better @leemcmullen ?

[leemcmullen]

@lbalmaceda Thanks for the heads up on that Luciano, I'd missed that part of the readme to be honest! My 2 suggestions to improve things slightly would be:

a) try to emphasise the point in the readme a little more i.e. that if there are uppercase characters in the package name on Android then it will fail to take you back to the app because of the conversion to lowercase behind the scenes when generating the redirect_uri.

b) try to improve the dev experience a little when there are uppercase characters present on Android. One suggestion might be to throw an error if there are uppercase characters in the scheme portion of the redirect_uri on Android (it seems to work fine on iOS) so at least the developer knows where to start looking. At the moment the auth browser just hangs with a spinner on the Sign In button, no obvious error gets logged and so it's difficult to know where to start troubleshooting.

It's probably a bit of an edge case but I've been stung by it in the past so chances are someone else might have been too! 😃

[lbalmaceda]

@leemcmullen It's a shame android behaves differently than other platforms on scheme capitalization... I like your suggestion of throwing an error when it contains uppercase chars. And will definitely give the readme a review. Thanks!

We're tracking this internally.

[lbalmaceda]

@leemcmullen I've opened a PR to try to improve this. Let me know what you think about it.