Severity: Info
Location: src/Servy/ViewModels/MainViewModel.cs:1320-1321
Code:
Password = dto.Password;
ConfirmPassword = dto.Password; // Assuming confirm = password
Explanation:
When an existing service's configuration is loaded into the Desktop app, Password and ConfirmPassword are both assigned from the same stored value. The inline comment ("Assuming confirm = password") admits the logic is an assumption rather than a verified invariant.
The practical problem: the password-confirmation field exists precisely so that a typo in Password can be caught before save. By pre-filling ConfirmPassword with the same value as Password on every reload, any subsequent edit to Password (e.g., user changes it to a new value) silently keeps the stale ConfirmPassword in sync until the user actually touches the confirmation box. Worse, if the user clears Password after a reload and types a new value only in Password, the old ConfirmPassword field is no longer visible to the validator since it's also been cleared and re-synced in the flow.
In short: the confirmation mechanism only does real work for new service installs; for edits, it's a no-op because the values are forced to match on reload before the user can introduce a divergence.
Suggested fix:
Either:
- Leave
ConfirmPassword blank on reload and require the user to re-enter it before allowing a credential change:
Password = dto.Password;
ConfirmPassword = string.Empty; // Force re-confirmation on any credential edit
- Or mark the password fields read-only on reload and surface a separate "Change credentials" affordance that clears both and requires explicit re-entry.
Option (1) is the minimal change and matches the user's mental model of "I have to type the password twice when I change it."
Note: option (1) will interact with the validator at src/Servy/Validators/ServiceConfigurationValidator.cs:168 which checks dto.Password == confirmPassword — Save of an unchanged service would then need to skip the confirmation check, or the reload path needs to recognize "no edits" and pass validation.
Severity: Info
Location:
src/Servy/ViewModels/MainViewModel.cs:1320-1321Code:
Explanation:
When an existing service's configuration is loaded into the Desktop app,
PasswordandConfirmPasswordare both assigned from the same stored value. The inline comment ("Assuming confirm = password") admits the logic is an assumption rather than a verified invariant.The practical problem: the password-confirmation field exists precisely so that a typo in
Passwordcan be caught before save. By pre-fillingConfirmPasswordwith the same value asPasswordon every reload, any subsequent edit toPassword(e.g., user changes it to a new value) silently keeps the staleConfirmPasswordin sync until the user actually touches the confirmation box. Worse, if the user clearsPasswordafter a reload and types a new value only inPassword, the oldConfirmPasswordfield is no longer visible to the validator since it's also been cleared and re-synced in the flow.In short: the confirmation mechanism only does real work for new service installs; for edits, it's a no-op because the values are forced to match on reload before the user can introduce a divergence.
Suggested fix:
Either:
ConfirmPasswordblank on reload and require the user to re-enter it before allowing a credential change:Option (1) is the minimal change and matches the user's mental model of "I have to type the password twice when I change it."
Note: option (1) will interact with the validator at
src/Servy/Validators/ServiceConfigurationValidator.cs:168which checksdto.Password == confirmPassword— Save of an unchanged service would then need to skip the confirmation check, or the reload path needs to recognize "no edits" and pass validation.