Closed dm-CaT closed 6 years ago
So Create/Update are the methods that actually persist the user, so updates to the poco need to happen before those methods are called to persist the user
Can you point me for some correct example how to implement custom UserStore?
The general idea is that Update/Create/Delete are the only methods that should persist to the backing store. All of the other methods should only be manipulating the user/role.
This case I need to have PasswordHash property for user class. It looks not so good, because I want to have possibility to pass user objects anywhere I need without sensitive information like PasswordHash. Even if it's hash.
You can store it somewhere else, it doesn't have to be a property on the user class
I tried to go this way but I cannot. I have to link password hash with user it belongs to, e.g. store it with user id. But when I have hash to store I do not have user id yet. That's my problem.
You will probably have to plug in a custom UserManager that switches the order of operations and CreateUser and then UpdatePasswordHash in your situation
Or maybe just use the username as the foreign key assuming you don't let people change that
User name as FK is not a choice. Looks like I have to implement a custom UserManager.
We periodically close 'discussion' issues that have not been updated in a long period of time.
We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.
Is there any reason why when the new user is created with password the password hash is set before user is saved? I'm trying to implement my own IUserStore/IUserPasswordStore (to use custom DAL). But I got an error because my store cannot set password hash (update record in DB) to non created user. Here is the code from UserManager which causes an error.
Link on method