Hello,
ASP Net Zero Core MVC was updated from 12.1 to 14.3. Then, a meeting was held for the Microsoft Dynamics 365 CRM Rest API token service based on the new version of our previous method. Specifically, we removed the Obselete body. Clearing the cache for the relevant cache in the application's admin panel creates a new token cache set. However, when a token expires within the application itself, reassigning the cache doesn't work properly. What could be the reason? DefaultSlidingExpireTime 55 min
App Version 14.3 Core MVC Node version 20.19.3 Yarn version 1.22.22 Npm version 10.2.4
Our service
public Dynamics365Token GetDynamics365TokenFromCache()
{
var cacheManager = _cacheManager.GetCache(Consts.CrmTokenCacheName);
return (Dynamics365Token)cacheManager.Get(Consts.CrmTokenCacheKey, model => GetDynamics365Token());
}
3 Answer(s)
-
0
I'm getting an error when I create a method with ICacheManager because the cache data hasn't been refreshed even though the cache time has expired. Where should I check? Additionally, I'm using the structure found here: https://aspnetboilerplate.com/Pages/Documents/Articles/How-To/add-custom-session-field-aspnet-core. However, even though the claims persist in the database in the services, the values in the session structure I created start returning null after a while. I suspect this is also related to the cache. I'm also experiencing this issue.
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image) -
0
Hi @tdv.yazilim
Token cache issue
In ASP.NET Zero, the cache mechanism is built on top of ICacheManager - IDistributedCache.
Sliding expire vs absolute expire
- Since you set
DefaultSlidingExpireTime = 55 min, the cache extends on every access. - That means if you fetch the token from cache frequently, the sliding expiration resets each time, and the token never actually expires in your cache even if it’s already expired in Dynamics 365.
- As a result, you keep getting the old token.
- Since you set
Behavior of
ICacheManager.Get(key, factory)- This method only runs the factory if the value is missing from cache.
- If the cached value is still there (kept alive by sliding expiration), the factory never executes, so you never get a refreshed token.
Fix suggestions:
- Use absolute expiration (
DefaultAbsoluteExpireTime) instead of sliding expiration, and align it with the Dynamics 365 token lifetime (e.g., 50 minutes absolute if the token lasts 55). - Store the token’s
expires_inwith the cache entry and refresh it before it expires. - Explicitly
Removethe old token (cacheManager.Remove(Consts.CrmTokenCacheKey)) before setting a new one.
Custom session field/claims disappearing
In ASP.NET Zero, custom session fields are usually stored in cache The issue here is similar:
- Once the cache expires, the claim/session values are gone.
- If you don’t reload them from the database, they will return as
null.
Fix suggestions:
- Ensure custom session fields can be reloaded from the database (for example, via
UserManager). - If you must cache, use absolute expiration + a refresh mechanism.
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image) -
0
Hi @oguzhanagir
Thank you for support. We applied this solution. We didn't experience this issue in older versions. We changed DefaultSlidingExpireTime to DefaultAbsoluteExpireTime for this caching.
Best regards.
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image)
