[PM-3836] Tools - Make Controllers, Services and API Models nullable#7212
[PM-3836] Tools - Make Controllers, Services and API Models nullable#7212
Conversation
|
New Issues (2)Checkmarx found the following issues in this Pull Request
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #7212 +/- ##
==========================================
- Coverage 57.62% 57.61% -0.01%
==========================================
Files 2033 2033
Lines 89619 89629 +10
Branches 7978 7992 +14
==========================================
+ Hits 51642 51644 +2
+ Misses 36117 36114 -3
- Partials 1860 1871 +11 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…ntrollers-Services-and-API-Models-nullable merge main
…oadDataResponseModel > nullable
…API-Models-nullable
|
| namespace Bit.Api.Tools.Models.Request.Accounts; | ||
|
|
||
| public class ImportCiphersRequestModel | ||
| { |
There was a problem hiding this comment.
| namespace Bit.Api.Tools.Models.Request.Organizations; | ||
|
|
||
| public class ImportOrganizationCiphersRequestModel | ||
| { |
There was a problem hiding this comment.
| }, sendAuthorizationService); | ||
| var data = new SendFileData(Name, Notes, fileName); | ||
| var send = ToSendBase(new Send { Type = Type, UserId = (Guid?)userId }, sendAuthorizationService); | ||
| var data = new SendFileData(Name ?? string.Empty, Notes, fileName); |
There was a problem hiding this comment.
Only the CLI can create or edit Sends having no name, the former behavior serialized and deserialized them as 'null', I've taken this opportunity to instead assign an empty string. Suggestions for a different default are welcome.
There was a problem hiding this comment.
I think empty string is fine, definitely an improvement over the former behavior. It does seem weird that the CLI is allowed to do that though, was that a deliberate design choice?
There was a problem hiding this comment.
I am not sure about this, I'd like to raise this with Product next time we sync. Typically, we strive for parity among clients. I didn't want to increase the scope of this work by making any changes in clients without raising this to product first; I think the CLI appeals to power-admins and wasn't sure if this would lead to any breaking changes in scrips used for batch generating Sends.
| break; | ||
| case Core.Tools.Enums.AuthType.Password: | ||
| existingSend.Password = authorizationService.HashPassword(Password); | ||
| existingSend.Password = authorizationService.HashPassword(Password!); |
There was a problem hiding this comment.
Clients all enforce that a password protected Send must have a password
| existingSend.Key = Key; | ||
| existingSend.ExpirationDate = ExpirationDate; | ||
| existingSend.DeletionDate = DeletionDate.Value; | ||
| existingSend.DeletionDate = DeletionDate!.Value; |
There was a problem hiding this comment.
This is safe since DeletionDate is required during model binding.
| Type = send.Type; | ||
| AuthType = send.AuthType ?? SendUtilities.InferAuthType(send); | ||
| Key = send.Key; | ||
| Key = send.Key!; |
There was a problem hiding this comment.
See Send propoerty definition for Key, it is guarenteed to be non-null
mcamirault
left a comment
There was a problem hiding this comment.
One question about a possible change and one question for my own curiosity
Looks great overall!
| }, sendAuthorizationService); | ||
| var data = new SendFileData(Name, Notes, fileName); | ||
| var send = ToSendBase(new Send { Type = Type, UserId = (Guid?)userId }, sendAuthorizationService); | ||
| var data = new SendFileData(Name ?? string.Empty, Notes, fileName); |
There was a problem hiding this comment.
I think empty string is fine, definitely an improvement over the former behavior. It does seem weird that the CLI is allowed to do that though, was that a deliberate design choice?
| else if (send.OrganizationId.HasValue) | ||
| { | ||
| metadata.Add("organizationId", send.OrganizationId.Value.ToString()); | ||
| } |
There was a problem hiding this comment.
❓ Should we add logic enforcing that the Send has to have one of UserId or OrganizationId in its metadata?
There was a problem hiding this comment.
I don't actually think we would gain much from this, but it also wouldn't hurt to be more defensive. I am not sure if this PR is the most appropriate place to make this change, mainly because I've tried to introduce behavioral changes only as strictly necessary to satisfy the compiler which is now enforcing nullability.
The throws introduced in this PR are not so much intended to tighten enforcement but instead replace the existing potential NullReferenceExceptions with exceptions wrapping an error message, they could have almost all been refactored from no-null-handling to using the null-forgiving operator and this would have more closely matched the behavior when #nullable disable was present in these files, but I think the throws both:
- indirectly document the expected variable state
- surface the same exception types, but with additional context
Right now, OrganizationId isn't actually being used in clients, and UserId is guaranteed to be assigned before the logic in this code is reached:
This assumes that _userService.GetProperUserId(User) does return a valid UserId, and if it does not, that case is already handled.
| metadata["userId"] = send.UserId.Value.ToString(); | ||
| } | ||
| else | ||
| else if (send.OrganizationId.HasValue) |





🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-3836
📔 Objective
Update Tools owned code to make Controllers, Services and API Models nullable
See related PR #7266