decide if better to swap default behavior and checkbox option
not too sure if there is a better way to detect initial lock screen. currently using the window.previousPopupUrl, which is modified after every NavigationEnd inside app.component.ts.
possibly tweaking timing. currently set to 100ms matching the element focus event.
The current unlock-and-fill procedure is just too slow and awkward, which you have to press the extension → unlock with biometrics → put your finger on the scanner. As I much prefer autofilling with the keyboard shortcut or using the experimental autofill on page load, I think the default action should be prompting you to unlock on any autofill action, whether it’s filling on page load, keyboard shortcut, or pressing on the extension.
Doesn’t seems like something hard to implement. If the team agrees, could start working on the code.
@allenhu1029 - I think this may fall in line with password re-prompt for some items, so users can decide if they want to use biometrics before filling in an item. @Hinton what do you think?
I had previously tried running a modified version of the old WIP PR for those features, but I wasn’t able to programmatically call openPopup due to security restrictions.
You can always create a new GitHub Contribution topic with full details of what you want to do and get it reviewed by someone on Bitwarden team.
@tgreer@cho-m I think this feature sounds great, one thing that pops to mind is that we would want to gracefully handle the desktop application not running. Opening the browser extension and getting a “start the desktop application” popup that needs to be immediately closed adds another prompt blocking the way. (Although it might be nice to inform the user we attempted to login using biometrics in a less intrusive way.
Based on a quick glance, I believe most of the messages are created inside NativeMessagingBackground.connect, so state data needs to be passed from LockComponent.ngOnInit to there.
I need to look further into whether storageService can be used for temporary data like this, or if some extra method parameters are needed.
May also take a look into using this.platformUtilsService.showToast for just displaying warning/error messages for this scenario.
Going from my memory I suspect adding another argument to platformUtilsService.authenticateBiometric would be preferred. It should provide a direct way to interact with the NativeMessagingBackground service. And might avoid the browser extension ending up in a weird state due to the popup closing unexpectedly.
I’m picking up where @cho-m left off and trying to get this feature across the finish line, but could use some guidance. I’m totally new to the Bitwarden codebase and learning as I go, any help is appreciated
This is where I’m stuck. I understand that the biometric flow starts in LockComponent.ngOnInit, and somehow we have to get a parameter (i.e. waitForDesktop) from there to NativeMessagingBackground.connect. If waitForDesktop is true, we show the dialog telling the user to start the desktop app, otherwise we just show a toast.
But I don’t understand how to pass such a parameter through the BrowserCryptoService, which I think is required for this to work. Could you point me in the right direction?
I haven’t looked at the code in a while, but it would seem reasonable to add an argument userInitiated: boolean = false to platformUtilsService.authenticateBiometric, which can get passed along to the biometricCallback. Which can then be handled in browser/main.background.ts at master · bitwarden/browser · GitHub to let the background service know it shouldn’t generate dialogs.
Thanks. Unfortunately life got in the way of following up on this. Is it really so bad if the browser extension prompts immediately to start the desktop application? I understand it might be a bit “startling” for the user, but it actually might save a few clicks and seems like the right UX.
The technical challenge with a more graceful fallback is that the unlock request has to traverse the BrowserCryptoService, which doesn’t (and probably shouldn’t) have any concept of user interaction. Whereas PIN and password auth handle UX (dialogs, toast) in the Lock UI itself, Biometric auth delegates all UX to the platform services.
@danep UX wise a non blocking toast seems more friendly than a blocking dialog. But feel free to implement it using the existing UX for now and we can look into improving it at a later time.
The interfaces changed fairly recently which muddles things, and I agree that cryptoService shouldn’t necessarily have knowledge of if the user imitated it or not.
@Samplex this feature is at the beginning of implementation. We’ll need to review and test before this moves into a release, which is done roughly every 5-6 weeks.
