user: implement password mutability via passwordRef#725
Conversation
Make the passwordRef field mutable so users can update passwords by pointing to a different Secret. Track the applied password reference in a new status field (appliedPasswordRef) to detect when an update is needed. The reconciler compares spec.resource.passwordRef with status.resource.appliedPasswordRef. On first reconcile after creation, it sets the status field without calling UpdateUser (CreateResource already set the initial password). On subsequent changes, it reads the new Secret, calls UpdateUser, and updates the status field via a MergePatch that coexists with the main SSA status update.
dlaw4608
left a comment
dlaw4608
left a comment
There was a problem hiding this comment.
Cool use of JSON Merge patches!!, looks ready to merge to me, if I had to point out one thing & this is in combination with the changes made in #726. These PR are adding a new mutability operation into the controller no? so then per the DOCS should we think about adding a new unit test for the actuator_test.go as well? , https://k-orc.cloud/development/writing-tests/.
I would be happy to take a crack at doing this in a follow up PR if you think it is necessary @mandre ?
Note: Also missing a unit test for the enabled field
You're absolutely right. Should we merge both PRs and you add the missing tests to |
2 participants
Make the passwordRef field mutable so users can update passwords by pointing to a different Secret. Track the applied password reference in a new status field (appliedPasswordRef) to detect when an update is needed.
The reconciler compares spec.resource.passwordRef with status.resource.appliedPasswordRef. On first reconcile after creation, it sets the status field without calling UpdateUser (CreateResource already set the initial password). On subsequent changes, it reads the new Secret, calls UpdateUser, and updates the status field via a MergePatch that coexists with the main SSA status update.
Fixes #723.