Closed bradmartin closed 5 years ago
K. After talking it out and poking around a bit. I went ahead and submitted a PR with a flow that I think makes sense for this plugin.
Feel free to handle how you want. Might make sense to modify it a bit if you want different behavior. I'll comment on the PR
hey @EddyVerbruggen - I know this is fingerprint auth so if you don't want to add the change just let me know.
Currently, if the android device has a fingerprint enrolled, then they are presented with the default security option PLUS the option to use the fingerprint to authenticate.
In some cases, they don't have the fingerprint enrolled but might have a passcode set.
I'm trying to think of a way to make a PR to this plugin that doesn't cause any breaking changes but I'm coming up short right now, maybe you have some thoughts since you're more familiar with the code base.
Right now I'm using the entire fingerprint-auth plugin as a way to prevent users from accessing sensitive material. I wanted it to fallback to whatever the user has configured regardless of fingerprint. I know that goes against the entire 'name' of the plugin π so maybe it's best to not mess with it. However, the following
isKeyguardSecure
method will return true if any security is configured so I'm just using it to resolve and then still presenting the user with the device security intent.I'm just not sure the best way to wrap this into a PR. Maybe the
available
call can add an optional argument to checkisDeviceSecure: boolean
and then we can still resolve on that method alone and of course it wouldn't have to returntouch: true
in that scenario.I'm not very clear on the iOS side yet as I haven't had to do a lot of digging there yet so maybe that change doesn't make sense to enable.