-
Notifications
You must be signed in to change notification settings - Fork 23
Error Changing User's Password #16
Description
Related Issue: 113 @ IdentityManager repo
When changing the user's password (or other UserMetadata property) via IdentityManager, the MembershipRebootIdentityManagerService first updates the user's property, but then updates the database with the old version of the account, therein reverting the user's new value with the old value.
The code in question can be found in MembershipRebootIdentityManagerService.cs, lines 503-511. From what I understand about SetUserProperty, the final update (line 511) is / should be redundant. SetUserProperty cannot actually change the value of the properties in account because all of the properties are protected internal set. Furthermore, SetUserProperty does not return the account that has the updated properties. Because of this, I think we're meant to assume that the functions called by SetUserProperty save their respective changes (although they should probably be done in a transaction?). Otherwise the assumption would be that the functions called by SetUserProperty change the properties of the instance of UserAccount passed in. I realize Entity Framework returns the same instance whenever you call it, but because it's not a hard dependency here, unless we're passing the same instance all the way until the save, that seems like an unsafe assumption.
With all of the above being the case, the final update (line 511 & its wrapping try-catch) is both redundant and a bug, especially when working with Mongo or any data layer that does not work exactly like Entity Framework.
Unless Entity Framework is going to become a hard dependency of this project, it should probably be the Set functions for the individual data layer implementations that should worry about when to persist rather than making it a concern of the MembershipReboot IndentityManager.