Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PM-16062 Prevent account locks for ongoing autofill requests #4498

Merged

Conversation

dseverns-livefront
Copy link
Collaborator

@dseverns-livefront dseverns-livefront commented Dec 20, 2024

🎟️ Tracking

PM-16062

📔 Objective

  • When the app was being opened by the AutoFill/Accessibility services from a cold start, the user would need to unlock the vault, and once completing the AutoFill request the vault was being locked based on the state being send to the VaultLockManager.
  • This was especially called out for logins that have a (2 page) flow, where the user was being asked to unlock the vault again to grab the password on the second page.
  • This change changes the VaultLockManager to check the timeout action instead on events of the activity being created for the first time with the added context of if was created for Autofill purposes.

📸 Screenshots

pm16062.mp4

⏰ Reminders before review

  • Contributor guidelines followed
  • All formatters and local linters executed and passed
  • Written new unit and / or integration tests where applicable
  • Used internationalization (i18n) for all UI strings
  • CI builds passed
  • Communicated to DevOps any deployment requirements
  • Updated any necessary documentation or informed the documentation team

🦮 Reviewer guidelines

  • 👍 (:+1:) or similar for great changes
  • 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
  • ❓ (:question:) for questions
  • 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed
    issue and could potentially benefit from discussion
  • 🎨 (:art:) for suggestions / improvements
  • ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
  • 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
  • ⛏ (:pick:) for minor or nitpick changes

…ly for autofill and update restart timeout to look at app created events
Copy link
Contributor

github-actions bot commented Dec 20, 2024

Logo
Checkmarx One – Scan Summary & Details312f80fe-1f8c-4228-96cf-f00e058b3d71

No New Or Fixed Issues Found

*/
CREATED,
data class Created(val createdForAutofill: Boolean) : AppCreationState()
Copy link
Collaborator

@brian-livefront brian-livefront Dec 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make this isCreatedForAutofill or wasCreatedForAutofill? I think that might fit boolean patterns in the app a little better. Or maybe even isAutofill, since the "created" part is already implied?

checkTimeoutReason = CheckTimeoutReason.APP_RESTARTED,
)
}
private fun handleOnCreated(createdForAutofill: Boolean, isFirstCreated: Boolean) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Borderline but if I remember correctly after the first param we'd usually break these onto new lines so its easier to add a 3rd, 4th, etc. later.

}
private fun handleOnCreated(createdForAutofill: Boolean, isFirstCreated: Boolean) {
val userId = activeUserId ?: return
userIdTimerJobMap[userId]?.cancel()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little nervous about moving userIdTimerJobMap[userId]?.cancel() to handleOnCreated now that I see this. I wonder if we need to keep handleOnForeground just for this. I believe the intention of this line is to say "whenever the app is foregrounded, we shouldn't have a timer going for the current user". In which case moving this here is a behavior change.

@@ -491,27 +486,37 @@ class VaultLockManagerImpl(

VaultTimeout.OnAppRestart -> {
// If this is an app restart, trigger the timeout action; otherwise ignore.
if (checkTimeoutReason == CheckTimeoutReason.APP_RESTARTED) {
if (checkTimeoutReason is CheckTimeoutReason.AppCreated) {
// On restart the vault should be locked already but we may need to soft-logout
// the user.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doc likely needs updating because right now its only discussing the firstTimeCreation case.

Copy link

codecov bot commented Dec 20, 2024

Codecov Report

Attention: Patch coverage is 95.00000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 88.93%. Comparing base (8548c74) to head (ea6f0d6).
Report is 18 commits behind head on main.

Files with missing lines Patch % Lines
...twarden/data/vault/manager/VaultLockManagerImpl.kt 94.44% 1 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff            @@
##           main    #4498       +/-   ##
=========================================
+ Coverage      0   88.93%   +88.93%     
=========================================
  Files         0      459      +459     
  Lines         0    39853    +39853     
  Branches      0     5638     +5638     
=========================================
+ Hits          0    35444    +35444     
- Misses        0     2441     +2441     
- Partials      0     1968     +1968     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

private fun handleOnForeground() {
val userId = activeUserId ?: return
userIdTimerJobMap[userId]?.cancel()
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we leave this function back where it was to make the diff a tiny bit smaller?

* @param createdForAutofill if the the creation event is due to an activity being launched
* for autofill.
*/
data class AppCreated(val firstTimeCreation: Boolean, val createdForAutofill: Boolean) :
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's update the formatting to

        data class AppCreated(
            val firstTimeCreation: Boolean,
            val createdForAutofill: Boolean
        ) :CheckTimeoutReason()

@dseverns-livefront dseverns-livefront added this pull request to the merge queue Dec 20, 2024
Merged via the queue into main with commit 6223f36 Dec 20, 2024
8 checks passed
@dseverns-livefront dseverns-livefront deleted the PM-16062-vault-locking-each-time-autofill-starts branch December 20, 2024 22:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Inline Tab Autofill Requires Unlocking Multiple Times Despite Session Timeout Settings
2 participants