[PM-5518] Refactor Email Token Providers #3784
Conversation
|
No New Or Fixed Issues Found |
kspearrin
changed the title
| } | ||
|
|
||
| public async Task<bool> ValidateAsync(string purpose, string token, UserManager<User> manager, User user) | ||
| { | ||
| var cacheKey = string.Format(CacheKeyFormat, user.Id, token); | ||
| var cacheKey = string.Format(CacheKeyFormat, user.Id, user.SecurityStamp, purpose); |
There was a problem hiding this comment.
Mirroring some of the implementation details from ASP.NET Core's EmailTokenProvider, which includes security stamp as a parameter in the token generation. We can include it as part of the cache key to get similar benefits.
|
One issue that I thought about here is self hosted customers who are using memory-based IDistributedCache (the default) will run into issues when token validation is needed across projects. For example, when using the "Send verification code email again" option, which happens from the API, but validation is done in Identity. Perhaps we should move that API endpoint to Identity? Or expect customers to start using a persistent cache implementation. Perhaps we could use SQL Server as a backing store. |
This concern is being addressed with #3791 |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #3784 +/- ##
==========================================
- Coverage 36.36% 36.36% -0.01%
==========================================
Files 1157 1158 +1
Lines 55884 55905 +21
Branches 5376 5377 +1
==========================================
+ Hits 20324 20329 +5
- Misses 34614 34631 +17
+ Partials 946 945 -1 ☔ View full report in Codecov by Sentry. |
Fixed tests |
Type of change
Objective
Refactor email token providers to use persistent
IDistributedCacheas the backing store for randomly generated tokens. This replaces existing TOTP functionality for email token, which has been determined to be inappropriate for our use cases of emailed tokens.Code changes
IDistributedCache. Remove code related to the two-factor use case.EmailTokenProviderfor two factor use cases. Does true token generation and validation instead of faking generation results with redacted emails like before.UserManager(base class) generate/validate two-factor token methods, which in turn calls into our newEmailTwoFactorTokenProvider.CoreHelpers.CustomProviderName(TwoFactorProviderType.Email)andTokenOptions.DefaultEmailProviderinstead of using the ASP.NETEmailTokenProvider.Before you submit
dotnet format --verify-no-changes) (required)