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-8352] Initial Fido2 User verification flow implementation #653

Merged
merged 14 commits into from
Jun 18, 2024

Conversation

fedemkr
Copy link
Member

@fedemkr fedemkr commented May 31, 2024

🎟️ Tracking

PM-8352

📔 Objective

Implement Fido2 User verification flow.

Note: This is an initial PR and the flow will be completed in subsequent PRs to ease

⏰ Reminders before review

  • Contributor guidelines followed
  • All formatters and local linters executed and passed
  • Written new unit and / or integration tests where applicable
  • Protected functional changes with optionality (feature flags)
  • Used internationalization (i18n) for all UI strings
  • CI builds passed
  • Communicated to DevOps any deployment requirements
  • Updated any necessary documentation (Confluence, contributing docs) 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

@fedemkr fedemkr requested review from a team and matt-livefront May 31, 2024 14:16
Copy link
Contributor

github-actions bot commented May 31, 2024

2 Warnings
⚠️ Ignoring duplicate libraries: '-lbitwarden_uniffi'
⚠️ BitwardenShared/UI/Auth/Utilities/UserVerificationHelper.swift has less than 80% code coverage
6 Messages
📖 BitwardenActionExtensionTests: Executed 0 tests, with 0 failures (0 expected) in 0 (0.004) seconds
📖 BitwardenAutoFillExtensionTests: Executed 0 tests, with 0 failures (0 expected) in 0 (0.001) seconds
📖 BitwardenShareExtensionTests: Executed 0 tests, with 0 failures (0 expected) in 0 (0.001) seconds
📖 BitwardenSharedTests: Executed 3219 tests, with 12 failures (0 expected) in 75.208 (76.317) seconds
📖 BitwardenTests: Executed 4 tests, with 0 failures (0 expected) in 0.576 (0.617) seconds
📖 NetworkingTests: Executed 26 tests, with 0 failures (0 expected) in 0.059 (0.067) seconds

Bitwarden code coverage

Total coverage: 86.35%

File Coverage
BitwardenShared/Core/Auth/Repositories/AuthRepository.swift 97.19%
BitwardenShared/Core/Auth/Services/LocalAuth/LocalAuthService.swift 100.00%
BitwardenShared/Core/Platform/Services/ServiceContainer.swift 97.33%
BitwardenShared/UI/Auth/Extensions/Alert+Auth.swift 100.00%
BitwardenShared/UI/Auth/Utilities/UserVerificationHelper.swift 79.01%
BitwardenShared/UI/Auth/Utilities/UserVerificationRunner.swift 100.00%
BitwardenShared/UI/Autofill/Utilities/Fido2UserVerificationMediator.swift 83.56%
BitwardenShared/UI/Platform/Application/Extensions/Alert+Extensions.swift 92.31%
BitwardenShared/UI/Platform/Settings/Extensions/Alert+Settings.swift 100.00%
BitwardenShared/UI/Platform/Settings/Settings/AccountSecurity/AccountSecurityProcessor.swift 98.71%

Powered by Slather

Generated by 🚫 Danger

Copy link
Contributor

github-actions bot commented May 31, 2024

Logo
Checkmarx One – Scan Summary & Details8b2eb545-9a94-47a0-827c-dd490c41fe33

No New Or Fixed Issues Found

/// Whether master password reprompt should be performed.
///
/// - Parameter reprompt: Cipher reprompt type to check
/// - Returns: `True` if master password reprompt should be performed, `False` otherwise.
Copy link
Contributor

Choose a reason for hiding this comment

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

⛏️ In general we don't capitalize true and false in doc comments


switch laError.code {
case .userCancel:
Logger.application.log("User cancel authentication")
Copy link
Contributor

Choose a reason for hiding this comment

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

⛏️ Maybe "User canceled authentication"?

func verifyPin() async throws -> UserVerificationResult
}

// MARK: DefaultUserVerificationHelper
Copy link
Contributor

Choose a reason for hiding this comment

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

⛏️ Usually our MARK comments for different top-level options (classes, etc.) are MARK: - to differentiate them from landmarks inside of a class.

///
protocol UserVerificationHelper {
/// Performs OS local auth, e.g. biometrics or pin/pattern
/// - Parameter because: The reason to be displayed to the user when evaluating the policy if needed
Copy link
Contributor

Choose a reason for hiding this comment

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

⛏️

Suggested change
/// - Parameter because: The reason to be displayed to the user when evaluating the policy if needed
/// - Parameter because: The reason to be displayed to the user when evaluating the policy if needed

Copy link
Contributor

Choose a reason for hiding this comment

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

🤔 I also kinda feel like this parameter would better be called reason, to match what we call similar things elsewhere in the app

Comment on lines 50 to 51
/// `verifyDeviceLocalAuth()` with device status not authorized.
func test_verifyDeviceLocalAuth_cant_perform_when_not_authorized() async throws {
Copy link
Contributor

Choose a reason for hiding this comment

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

🎨 I feel like our usual pattern with tests is to make the test name somewhat more terse, generally of the test_function_condition variety, with each unit camelcased—so test_verifyDeviceLocalAuth_notAuthorized here—and to put the fuller explanation of the Given/When/Then in the comment, since that's easier to read.

func verifyWithAttempts(
verifyFunction: () async throws -> UserVerificationResult
) async throws -> UserVerificationResult {
var attempts: Int8 = 0
Copy link
Contributor

Choose a reason for hiding this comment

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

❓ Why Int8 instead of Int for just counting? The Swift language guide indicates that we should always use Int unless there's a good reason to do otherwise.

Copy link
Member Author

Choose a reason for hiding this comment

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

I just thought that given it counts "attempts", one would never use hundreds or thousands of attempts so Int8 (maximum 127) made sense. Maybe I could even have used UInt8 to indicate that attempts shouldn't be negative. I can make it Int if performance is better or something like that. IMO even though is negligible for performance I often try to use the necessary data type instead of the broader one.

Copy link
Contributor

Choose a reason for hiding this comment

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

It's a good instinct, and one that I had coming from Objective-C, but Swift really pushes to use the base types (Int, Double, etc.) unless absolutely necessary. I assume there's some sort of compiler optimization that happens around those base types, and I've also occasionally run into issues doing math when I had competing types (though that was also a Very Long Time Ago so it might not be an issue now). It's relatively moot here, however.

Copy link
Member Author

Choose a reason for hiding this comment

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

Given that in this case it's pretty much the same and the performance gain is negligible, I'll just change it to avoid confusions.

/// An enum with the possible results when verifying a user
///
enum UserVerificationResult {
case cantPerform
Copy link
Contributor

Choose a reason for hiding this comment

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

🎨 Using a contraction here feels weird to me. I think a more idiomatic way would be unableToPerform

XCTAssertEqual(result, .passcodeNotSet)
}

/// `evaluateDeviceOwnerPolicy(suppliedContext:,deviceAuthStatus:,localizedReason:)`
Copy link
Contributor

Choose a reason for hiding this comment

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

⛏️ Generally when giving a Swift function that takes multiple parameters, just the colons are used: evaluateDeviceOwnerPolicy(suppliedContext:deviceAuthStatus:localizedReason:). It's a little weird, but it's a holdover from the Objective-C days (when there weren't commas between function arguments like that).

Copy link
Collaborator

Choose a reason for hiding this comment

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

Tip: you can get the symbol name by right clicking the function > Copy > Copy Symbol Name. Or ^⇧⌘C is the default shortcut.
Screenshot 2024-06-04 at 2 20 27 PM

matt-livefront
matt-livefront previously approved these changes Jun 5, 2024
Copy link
Collaborator

@matt-livefront matt-livefront left a comment

Choose a reason for hiding this comment

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

Looks good to me!

Copy link
Collaborator

@matt-livefront matt-livefront left a comment

Choose a reason for hiding this comment

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

👍

@fedemkr fedemkr merged commit c0de781 into main Jun 18, 2024
5 checks passed
@fedemkr fedemkr deleted the mobiletf/pm-8352/fido2-user-verification-flow branch June 18, 2024 18:39
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.

3 participants