mjwheatley / cordova-plugin-android-fingerprint-auth

A cordova plugin for fingerprint authentication using the hardware fingerprint scanner on devices running Android 6+
Apache License 2.0
168 stars 131 forks source link

Fingerprint Auth FAILS After Putting App In Background After Logout #95

Closed howdoesthisthingwork closed 6 years ago

howdoesthisthingwork commented 6 years ago

Steps to reproduce:

  1. Logout of app, so user is back on login screen and fingerprint modal will show.
  2. Navigate away by hitting home button or going to other app.
  3. Go back to the app.
  4. Modal for fingerprint will be showing.
  5. Try to login with fingerprint.

Result:

  1. Login will fail, although modal will saw fingerprint recognized.
  2. Modal will close and user will see login screen (or whatever behavior is designed to be behind the modal)
  3. Nothing happens and user will be confused as to why the fingerprint says it was recognized but nothing occurred.

Our Suspicion After going into the background, whatever picks up the fingerprint authentication is no longer listening to the event and therefore not triggering the behavior that should occur afterwards.

mjwheatley commented 6 years ago

I am not able to replicate this issue. I have tested on a Nexus 6p running Android 8.0.0 and this has worked on previous version down to Android 6.0 and has worked on emulators as well. This may either be device specific or an implementation error.

What device are you experiencing this issue on? Have you tested on any other devices? Can you provide a snippet of your implementation? Are there any messages in the logcat that could indicate that the plugin has tried to return a response?

mjwheatley commented 6 years ago

Perhaps you can revise your issue. This modal does not deal with logging in and out of an application. It merely handles the authentication result of fingerprint sensor.

In result 1 you mention that modal displayed fingerprint recognized, but your login fails. If the fingerprint was recognized we need to check if the plugin has attempted to return a response. If it has, and your success callback is not being called, maybe there is something going on with the context of your async callback. What framework are you using for your app, Cordova, Ionic, Meteor, other?

Please help determine the conditions to replicate your issue or provide a link to a sample repo demonstrating the issue so more research can be performed.

shivam-jtg commented 6 years ago

I have tested It on Redmi 3S prime. As suggested in #96 now I am not opening new prompt onResume of app. But when I scanning finger It is showing fingerPrint recognized but success callback had not been called.

mjwheatley commented 6 years ago

@shivam-jtg I'm guessing the callback works correctly if the app does not go to the background, is that right? Check the logcat and see if the plugin is returning a result.

Provide a snippet of your code calling the plugin and your callback methods.

Create a new Cordova app, add the plugin, and create a single button UI to launch the plugin. If that reproduces the issue please create a Git repo and send me a link.

russaa commented 6 years ago

I have experienced similar symptoms and discovered that the problem arose in combination with an isAvailable call:

since the plugin always stores the callback-reference from the last call, if decrypt and isAvailable get called --before waiting that the other one has finished-- the first of the callback-references gets replaced by the later one, and then that (2nd) callback-reference is invoked twice (Cordova prints a warning message about the 2nd invocation).

So if you first call decrypt (or decrypt is still waiting for the user-interaction) and then call isAvailable, the decrypt-call will most probably try to send its result via the isAvailable-callback by using it a second time.

A solution to this: make sure, that all calls to the plugin have returned, before issuing a new one.

It might be worth considering, treating the isAvailable-call (that is its callback-reference) differently than the others -- since it is unlikely, encrypt and decrypt will be called concurrently, but isAvailable might be.
For instance, in my code is was part of a default-check that was triggered from some other code than the decrypt call.

mjwheatley commented 6 years ago

Closing as implementation issue.