0
codescientists created
Using Version 10.0, Angular/Core
I have tested the two-factor auth (only with email) and am seeing some issues (haven't found these from searching so far).
- If 2FA is enabled & active for a user they can log in the first time. If they log out and log back in (with 2FA code each time) it will work. But after a while we will always get "Security code could not be sent!". I notice that the cache is set early (in
TokenController.Authenticate
instead of at the time where the code is generated inTokenController.SendTwoFactorAuthCode
). From debug I find that the call toITypedCache<string,TwoFactorCodeCacheItem>.Set()
does NOT actually set in values in memory, past a certain point in time. - I notice the cache has two different "expiration" settings. Looking in the [project]WebCoreModule.cs I can see that for the 2-factor code cache, the cache's
DefaultAbsoluteExpireTime
is set. In debug I can see that this is configured once on first instance of needing the 2-factor code cache. It is set to 2 minutes. So it seems like if an absolute expire time is set for the whole cache, no entries are settable or retrievable after that time. I don't know if this can be confirmed from the ABP code underlying but it seems to be what's happening. Why isDefaultSlidingExpireTime
not used instead? This seems to fix the issue, and allows a new expiration "per item" instead of one global/permanent expiration for all future cache entries. Could this be happening with other cache-based operations? I am only just getting started with our project. - In the angular UI, once the code is sent, a timer indicates "90 seconds" but this is unrelated to the 2 minutes established on the API side. I can see this is hard-coded. Shouldn't the API return info about how long the code will last at the time it is generated?
1 Answer(s)
-
0
Hi,
Thank you for reporting this. There was a recent change about cache system and it seems like this part is not updated correctly. Please follow https://github.com/aspnetzero/aspnet-zero-core/issues/3703. We will fix this problem.
Thanks again.