Handle Login Drift #1132
Handle Login Drift #1132
Conversation
For years, we've been beset by a small number of users losing access to their accounts, needing manual reset at extremely inopportune times. After a good deal of code review and web searching, I've finally discovered that a) this is normal and b) there is a simple bit of code that can be used for automatic and instantaneous account recovery. I've tested this by mangling my local DB ProviderKey values, and observing that it successfully self-heals with the user being none the wiser. Fixes PuzzleServer#1073, though does it in a better way than expected.
| // Search the codebase for "RequireUniqueEmail" for the code that requires this. | ||
| services.Configure<IdentityOptions>(options => | ||
| { | ||
| options.User.RequireUniqueEmail = true; |
There was a problem hiding this comment.
Note that I have not verified that emails are actually unique at present; I would not be surprised if some staffers have some duplication generated during server development, or perhaps some migrations have left stale users behind. Verification/cleanup is required before this code can be merged.
There was a problem hiding this comment.
I've had to delete the existing AspNet user in order to fix this issue in the past, so I suspect there are few to no duplicates.
|
Actually, if you agree that the query below is the right query, we may be all set as it returns zero results: |
Yes, this is good |
|
I don't think we have any way to verify that this is what's causing our problem, but I don't see any downsides to trying it and it sets us up for the multiple logins feature, which is a nice bonus. :) This is exciting! |
| // Search the codebase for "RequireUniqueEmail" for the code that requires this. | ||
| services.Configure<IdentityOptions>(options => | ||
| { | ||
| options.User.RequireUniqueEmail = true; |
There was a problem hiding this comment.
I've had to delete the existing AspNet user in order to fix this issue in the past, so I suspect there are few to no duplicates.
For years, we've been beset by a small number of users losing access to their accounts, needing manual reset at extremely inopportune times.
After a good deal of code review and web searching, I've finally discovered that a) this is normal and b) there is a simple bit of code that can be used for automatic and instantaneous account recovery.
I've tested this by mangling my local DB ProviderKey values, and observing that it successfully self-heals with the user being none the wiser.
Fixes #1073, though does it in a better way than expected.