Version: 14.0 Environment: C# (Asp.net zero core app)
Background: I created a private session implemented as claims (Similar to OrganizationUnit) as it needs to be switched within app usage.
Expectations: The Session variables /claims will be stored in AbpUserClaims Reality: The session variables/claims are being stored in AbpSettings. (this is a potential security issue, being mixed up with permanent settings)
Expectation: Session variables/claims value should remain same no matter how many times you refresh or call it until changed.Once changed, it retains the new value and remains same in each call. this is especially understandable since it saves it in db and retrieves from db. Reality: It remains as expected during tests or deployed on a single worker thread. However, once deployed in IIS with multiple workers, it becomes a russian roulette when you make update your session variables, multiple calls seem to return either the changed value or previous value. Mostly new value but 1 out of 5 returns the old value.(we have 10 worker threads).
1 Answer(s)
-
0
Hi @ayoyusuf
Thanks for the detailed explanation.
AbpUserClaimsandAbpSettingsare used for different purposes.AbpUserClaimsis the ASP.NET Identity claim store. Claims from this table are loaded when the user'sClaimsPrincipalis created, for example during sign-in or principal refresh. UpdatingAbpUserClaimsdoes not automatically update an already issued cookie/JWT token.If your custom “private session” value is implemented with
ISettingManager.ChangeSettingForUserAsync, then storing it inAbpSettingsis expected. That API is for user settings, not user claims.The random old/new value behavior under IIS is most likely caused by cache isolation between multiple IIS worker processes. ABP caches user settings in
AbpUserSettingsCache. With the default in-memory cache, each worker process has its own cache. When one worker updates the setting, only that worker invalidates its local cache; other workers may continue returning the old value until their cache expires. This explains why the value is consistent with a single worker but becomes random with multiple workers.To solve this, please use a distributed cache such as Redis for ABP caching, or run the application with a single worker process. In ASP.NET Zero, Redis support is already available, but
Configuration.Caching.UseRedis(...)is commented out by default in the web module. You need to enable it and configure the Redis connection string.Also, if this value is security-sensitive or should be scoped to a specific login/session/device, we do not recommend storing it as a user setting. User settings are persistent per user. In that case, use a server-side custom table/cache keyed by user/session token, and always validate the selected value on the server side. If you decide to store it as a claim, the authentication cookie/JWT must be regenerated after switching the value.
Thank you
Markdown is supportedCopy & paste or drag & drop images (max 30 MB per image)
