[PM-27278] add AccountKeysRequestModel to RegisterFinishRequestModel for account encryption v2 support#6798
[PM-27278] add AccountKeysRequestModel to RegisterFinishRequestModel for account encryption v2 support#6798
Conversation
…ed up reference to master password hash
…d more comments and fixed up some long lines.
…unts controller no longer nullish allowed.
…e thrown error messages more appropriate
…tModel.cs Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
…ed comments for tests.
…t additions to make sure properties that were once required are still required.
…ted tests and added comments for the future.
…ed new checks from review.
…tModel.cs Co-authored-by: Maciej Zieniuk <167752252+mzieniukbw@users.noreply.github.com>
…d new checks for master password authentication data.
…ved invalid check.
…fled around validation checks to the request model instead of the controller.
…Added comments to clarify how these data types should be used.
…Updated docs around the validation
…Removed troublesome null safeguarding.
…Removed debug file.
…Fixed error in register finish model validation.
…ed accounts controller tests.
…essed concerns from reviewer.
…d up tests a little more.
|
Addressed @quexten's comment and merged main into branch. Had some issues with the merge, apologies for the force push, hopefully should be cleaned up now. |
cc33e95 to
66c3938
Compare
|
@quexten @enmande @mkincaid-bw the changes have now passed QA. The only changes to the code since the last time you reviewed should be updating the date for the DB migration script. |
| @@ -0,0 +1,26 @@ | |||
| CREATE PROCEDURE [dbo].[User_SetMasterPasswordUnlockUserData] | |||
There was a problem hiding this comment.
We've had some discussion about naming conventions recently and User_SetMasterPasswordUnlockUserData does not align with our current standards (I'm in the process of updating the Contributing Docs to try to clear some things up). The convention should be something like User_Update.... You can look at existing User_Update procs for examples.
My apologies for not mentioning this in my original review.
|



🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-27278
Stacks on top of #6855.
📔 Objective
Deprecating V1 User Asymmetric Key information in favor of new V2 User Asymmetric Account Keys structure.
This PR adds support for the new
AccountKeysstructure while maintaining support for the legacyUserAsymmetricKey-based flow. Validation is updated to check eitherAccountKeysorUserAsymmetricKeysare updated. Tests include modeling for both scenarios.📸 Screenshots
⏰ Reminders before review
🦮 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