Skip to content
This repository has been archived by the owner on Feb 15, 2018. It is now read-only.

Error Changing User's Password #16

Open
LaoArchAngel opened this issue Aug 31, 2015 · 1 comment
Open

Error Changing User's Password #16

LaoArchAngel opened this issue Aug 31, 2015 · 1 comment
Labels

Comments

@LaoArchAngel
Copy link

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.

@brockallen
Copy link
Member

Wow, I really let this issue slip thru the cracks. Not sure how I missed this for so long...

anyway, did you do anything to work around this?

@brockallen brockallen added the bug label Aug 13, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

2 participants