Inconsistent Error Messages Between iOS and Android for Cancelled Biometry Operations
Hello, I've come across an inconsistency in the error messages provided by react-native-keychain version 8.1.2 when a user cancels a biometry operation.
Steps to reproduce:
- Prompt the user for biometric authentication using react-native-keychain.
- On the biometric prompt, click "Cancel" or the equivalent option.
Expected Result:
A consistent error message for both iOS and Android.
Actual Result:
iOS: The error message is "User canceled the operation." Android: The error message is "code: 13, msg: Cancel".
Possible Solutions:
It would be beneficial for the development community if there was consistency in the error messages across platforms. One of the following solutions could be considered:
Standardize the error message across both platforms. Export the instance of the error in order to manipulate them more easily.
Additional Information:
React Native Version: 0.72.3 Device(s) Tested On: iPhone 13 / OnePlus6T OS Version: iOS 16.1.1 / Android 11.1.2.2
Yes this would be nice. There's also another case you need to handle where the user hit the back button on Android (there's no cancel button on the Samsung Knox implementation!). There might be more, but these are the ones we found on our array of test devices.
catch (e) {
const stringifiedError = JSON.stringify(e)
if (
(e && typeof e === 'object' && 'code' in e && String(e.code) === '-128') || // iOS cancel
stringifiedError.includes('code: 13') || // android "log out" pressed
stringifiedError.includes('code: 10') // android cancel via back button
) {
// Handle cancel
}
For context I believe the error codes match up with this https://developer.android.com/reference/androidx/biometric/BiometricPrompt#constants_1
https://github.com/oblador/react-native-keychain/blob/5fc9e8b21d7ef4ae9130c091e1e1d793085827aa/android/src/test/java/com/oblador/keychain/decryptionHandler/DecryptionResultHandlerInteractiveBiometricTest.java#L27
Hey @AntoineThibi, I appreciate you raised this issue a couple of years ago! I thought it might be useful to get your feedback on the following PR that looks to address these inconsistencies using standardised error codes: #762 👍
Hey @lewie9021 ! Awesome! Great work for this PR, it is exactly what I would have like. I just think you can add the description of the error inside the enum or in the README. This way other users will be able to look at it and directly understand what the error means.
#762