You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 15, 2018. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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 inaccount
because all of the properties areprotected 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 bySetUserProperty
save their respective changes (although they should probably be done in a transaction?). Otherwise the assumption would be that the functions called bySetUserProperty
change the properties of the instance ofUserAccount
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.The text was updated successfully, but these errors were encountered: