MvcCurrentApplicationConfigurationCacheResetEventHandler，HandleEventAsync Problem #10259

5 Answer(s)

• 

  0

  AI-Bot created 12 hours ago

  Support Team ABP Agent

  1. What is happening

  • MvcCachedApplicationConfigurationClientHelper.CreateCacheKey(CurrentUser) builds a cache key per user (tenant + user id + culture).
  • MvcCurrentApplicationConfigurationCacheResetEventHandler.HandleEventAsync does:

  public virtual async Task HandleEventAsync(CurrentApplicationConfigurationCacheResetEventData eventData)
    {
        await Cache.RemoveAsync(CreateCacheKey());
    }
  
    protected virtual string CreateCacheKey()
    {
        return MvcCachedApplicationConfigurationClientHelper.CreateCacheKey(CurrentUser);
    }
  

  • CurrentUser here is the user who is executing the current request (the one who publishes CurrentApplicationConfigurationCacheResetEventData).

  So when your admin user changes settings/permissions and triggers the reset event, the handler removes only the admin’s cache entry, because CurrentUser is admin.
  Other users’ cache keys remain in Redis and expire only when the cache timeout (5 minutes) is reached. That matches exactly what you’re seeing: “deleted is always admin, other users can’t be deleted, only wait 5 minutes timeout”.

  This is by design: CurrentApplicationConfigurationCacheResetEventData is meant to reset the current user’s application configuration, not all users.

  ---

  2. Why you cannot invalidate other users’ caches from admin

  • The application‑configuration cache is per client / per user.
  • The server does not know which user is currently using which cache key on which browser/instance; the only safe thing it can do synchronously is “invalidate current user”.
  • Therefore, when admin changes other users’ permissions, ABP does not automatically clear those users’ configuration caches. They get fresh config only when:
    • Their own client calls /api/abp/application-configuration again and refreshes its cache, or
    • The existing cache entry expires.

  ---

  3. Options / Workarounds

  Choose depending on your requirement:

  A. Accept per-user behavior (recommended, simplest)

  If it is acceptable that other users see updated permissions after at most 5 minutes (or after they refresh / re-login), then you don’t need any change. This is ABP’s default behavior.

  You can lower the cache duration if 5 minutes is too long by customizing distributed cache options for ApplicationConfigurationDto, but that increases load:

  Configure<AbpDistributedCacheOptions>(options =>
  {
      options.CacheConfigurators.Add(cacheName =>
      {
          if (cacheName == typeof(ApplicationConfigurationDto).FullName)
          {
              return entryOpts =>
              {
                  // e.g. 1 minute
                  entryOpts.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(1);
              };
          }
  
          return null;
      });
  });
  

  ---

  B. Disable application-configuration caching completely

  If you prefer always fresh config and can accept more backend traffic:

  Configure<AbpAspNetCoreMvcClientOptions>(options =>
  {
      options.CacheApplicationConfiguration = false;
  });
  

  Then MvcCurrentApplicationConfigurationCacheResetEventHandler effectively becomes unnecessary because nothing is cached.

  ---

  C. Implement your own global cache invalidation (advanced, not built-in)

  If you really need “when admin changes something, all users must see it immediately”:

  1. Keep using distributed cache, but:

     • Do not use a per-user cache key.
     • Or maintain an additional “version” value in cache and include it in the key to force global refresh.

  2. That would require:

     • Replacing the default MvcCachedApplicationConfigurationClient (or helper) to use your own cache key strategy.
     • Possibly writing a custom event handler that either:
       • Clears a global key, or
       • Increments a “configuration version” value that becomes part of per-user keys.

  This is not provided out-of-the-box; you must implement and test it yourself.

  ---

  4. Answer to your direct question

  • MvcCurrentApplicationConfigurationCacheResetEventHandler.HandleEventAsync always uses the CurrentUser of the request that fired the event.
  • In your scenario, that is always the admin user operating in the back office, therefore only admin’s cache entries are removed.
  • Other users’ application configuration cache entries are not removed by this event and will only refresh when:
    • Their own client re-requests configuration, or
    • The cache expiration time is reached.

  If you need immediate reflection for other users, use option B (disable cache) or implement a custom global invalidation strategy as in option C.

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Save Cancel
• 

  0

  maliming created 12 hours ago

  Support Team Fullstack Developer

  hi

  删除的一直都是admin，其他用户无法删除，只能等待5分钟超时

  请分享一个用例? 什么样的操作?

  详细的步骤是?

  谢谢

  Save Cancel
• 

  0

  heshengli created 12 hours ago

  1 FeatureManagementModal、PermissionManagementModal等时，没有带上参数吧 MvcCurrentApplicationConfigurationCacheResetEventHandler实现，CurrentUser 是当前操作人吧 await LocalEventBus.PublishAsync( new CurrentApplicationConfigurationCacheResetEventData() ); 2 User => Test， 单一角色权限【用户管理、角色管理】，admin取消角色管理权限，test 5分钟生效。 User =>admin， 单一角色权限【用户管理、角色管理】，admin取消角色管理，刷新页面立刻生效。

  3 2 User => Test， 多角色权限 Role1【用户管理】、Role2角色管理，admin取消Test的Role2角色，test 后台5分钟生效，菜单不消失，访问403。

  Save Cancel
• 

  0

  maliming created 12 hours ago

  Support Team Fullstack Developer

  好的, 我检查一下. 👍

  Save Cancel
• 

  0

  maliming created 10 hours ago

  Support Team Fullstack Developer

  hi

  You can use the code in this PR to fix it temporarily.

  https://github.com/abpframework/abp/pull/24486

  Thanks.

  Save Cancel