Handle incomplete promise in web authentication

[poovamraj]

Changes

We have a issue in our RNA where the promise for web authentication remains incomplete if the user moves out of the app in between the login.

This is happening because React Native opens the root instance of a task because it uses launch mode as singleTask which usually doesn't happen in Android apps.

To fix this we handle the onNewIntent and reject the promise that the user has cancelled the authentication.

References

#785

Testing

The changes have been tested manually

• This change adds unit test coverage
• This change has been tested on the latest version of the platform/language or why not

[rick-lannan-upgrowth]

Hi @poovamraj, it seems this PR forces a cancellation of the promise when the auth window is closed prematurely. Whilst this is valid for unknown events which cause the auth window to be closed, I would argue that stopping the auth window from being closed when the app is backgrounded and relaunched via the app icon or a deep link is also required (you mentioned on #785 this should be possible). The reasoning is it's completely normal for a user to background the app during an auth flow to open their email or sms app if there is an auth0 action that requires email verification or 2FA enrolment as part of the login flow

For example, if email verification is required on registration, if the user does the verification on the same device and then relaunches the app via the app icon, this would result in a broken registration process where the auth window disappears and the app is in an a signed out state. And it would not be evident to users that their account has actually been created already and they need to do a Sign In and not another Register. I know this to be the case as this is what happens in the v2 version of the package as it does something similar with the a0.session.user_cancelled error

In our current implementation using the v2 version of the package, we ended up fixing the broken registration flow with a complicated solution looking for the a0.session.user_cancelled error and if on Android, attempting a silent auth using webAuth.authorize with { "prompt": "none, "screen_hint": "login" } - this results in an automatic recovery of the broken registration flow by automatically signing the user in if they've completed their email verification... but it shouldn't be the responsibility of the consuming application to handle this. Whilst we could just leave that workaround in place it really should be fixed at the package level. This would also standardise the experience on IOS and Android

Can I also suggest that we use a different code to a0.session.user_cancelled for unknown events which cause the auth window to be closed as it's not a user triggered cancellation, but rather that the auth overlay was dismissed by the OS. Having a separate code means the calling application can differentiate between a cancel triggered by the user or a cancel due to a failed auth process

[poovamraj]

@rick-lannan-upgrowth I understand this and that is the intention of the SDK as well. But there is a limitation in react-native where it forces to create a new task from the root when the app is opened as you can see here. This means no matter what we do in our SDK a new task will be created from the root because of how React Native is configured.

You can override this behaviour by setting the AndroidManifest.xml to the following

  <application>
      <activity
          android:name=".MainActivity"
          android:label="@string/app_name"
          android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|screenSize|smallestScreenSize|uiMode"
          android:windowSoftInputMode="adjustResize"
          android:exported="true">
          <intent-filter>
              <action android:name="android.intent.action.MAIN" />
              <category android:name="android.intent.category.LAUNCHER" />
          </intent-filter>
      </activity>
  </application>

All this basically does is removes the launchMode from how React Native sets it and you can achieve the behaviour you are asking for. But this is changing the internal behaviour of React Native and that wouldn't be recommeneded behaviour

About the error message, I agree that this can be a more unique error message. We will update it from our end 👍