Check the docs before asking a question: https://abp.io/docs/latest Check the samples to see the basic tasks: https://abp.io/docs/latest/samples The exact solution to your question may have been answered before, and please first use the search on the homepage.
Provide us with the following info:
🧐 Hint: If you are using the ABP Studio, you can see all the information about your solution from the configuration window, which opens when you right-click on the solution and click on the Solution Configuration button.
- Exception message and full stack trace:
- Steps to reproduce the issue:
Environment
- ABP Commercial 10.5.0 (also reproduced on 10.6.0; absent on 10.4.0 and 10.3.0)
- ASP.NET Core / .NET 10, MVC + Razor Pages (LeptonX; 5.4.0 on the passing build, 5.5.0 on the failing build) + React SPA
- EF Core on Azure SQL (shared DB), Redis distributed cache shared across two App Service deployment slots, OpenIddict
- Multi-tenant (Volo.Saas host + tenants); cookie authentication on the Razor surface
- The affected user exists in every tenant with the same user Id
Summary
After upgrading past 10.4.0, identity sessions created by fresh cookie logins become invalid as soon as the user re-authenticates (sign-out + sign-in) a second time within the same browser session. The cookie still carries the SessionId claim, but IdentitySessionChecker cannot find that SessionId, and the dynamic-claims contributor force-logs the user out. Reproduces 100% of the time in our automated suite.
Note on patch versions: our commercial NuGet feed shows only 10.5.0 and 10.6.0 stable in this range (then 10.7.0-rc.2 / 10.8 previews, which our production policy excludes), so "upgrade to the latest patch" is not currently an available answer for us — hence the detailed report.
Version isolation
We deployed an identical application tree four times, changing only the ABP package set:
- 10.3.0 — baseline, passes
- 10.4.0 — passes
- 10.5.0 — fails (ABP 10.4.0 to 10.5.0, LeptonX 5.4.0 to 5.5.0 are the only deltas vs the passing build)
- 10.6.0 — fails
The verification suite is ~100 Playwright tests including dozens of tenant re-authentications. It passes fully on 10.4.0 and fails from the second re-authentication onward on 10.5.0/10.6.0, 100% reproducible.
Exact repro (single user, single browser context)
- Fresh cookie login on tenant A (admin user). Session works.
- First re-auth: sign out, sign in under tenant B (same user Id exists there). Session works; pages render.
- Second re-auth: sign out, sign in under tenant C. The resulting cookie carries a SessionId claim that IdentitySessionChecker cannot find, and the next request force-logs the user out.
Log signature at step 3 (Serilog):
[WRN] [Volo.Abp.Identity.Session.IdentitySessionChecker] Could not find SessionId(3f9dd7e8-4d24-47c8-bad8-a2fe0423926f) in the database.
[WRN] [IdentitySessionDynamicClaimsPrincipalContributor] SessionId(...) not valid for user: d4cb6ca4-..., log out.
[WRN] [IdentitySessionDynamicClaimsPrincipalContributor] The token is no longer valid because the user's session expired.
[ERR] [Volo.Abp.Account.Public.Web.AbpAccountPublicWebModule] SessionId is null. It's not possible to revoke the session during sign out.
During the failing sign-out/sign-in sequence we also see (may be cause or symptom — flagging for your attention):
[WRN] [Volo.Abp.EntityFrameworkCore.AbpDbContext] There is an entry which is not saved due to concurrency exception
Volo.Abp.Data.AbpDbConcurrencyException: The database operation was expected to affect 1 row(s), but actually affected 0 row(s)
(On 10.4.0 an occasional optimistic-concurrency warning appears on IdentityRoleStore during login and is benign; on 10.5.0 the session becomes unfindable.)
Additional observations
- We verified directly in the database that the missing SessionId rows are truly ABSENT from AbpSessions — this is a write-side loss (insert never committed, or created and immediately deleted), not a lookup/visibility problem.
- Sessions created under 10.3.0 BEFORE the upgrade keep working after the upgrade, across unlimited tenant switches, even while the app runs 10.5.0. Only sessions created by 10.5.0 code die. So validation of old sessions works; creation (or immediate revocation) of new sessions is what changed.
- The failure pattern (first re-auth OK, second re-auth broken) suggests revocation of the previous session racing with — or deleting — the newly created session during the back-to-back SignOut + SignIn in one request pipeline. The re-authentication in our app is your Account Pro LinkUsers switch flow.
- We attempted IdentitySessionCheckerOptions.UpdateSessionAfterCacheHit at large values as a mitigation; sessions still died and authenticated requests began to hang, so we reverted it.
- The 10.4-to-10.5 migration notes on single-active token provider semantics are our prime suspect, but the behavior lives in the closed-source Pro assemblies so we cannot confirm.
Second issue: Hangfire TypeLoadException after 10.6.0 upgrade
(If your process requires this as a separate ticket, please say so and we will split it.)
On 10.6.0 with the ABP Hangfire integration, this throws every ~15 seconds:
Hangfire.Common.JobLoadException: Could not load the job
---> System.TypeLoadException: GenericArguments[0], 'Volo.Abp.BackgroundJobs.BackgroundJobWorker', on 'HangfirePeriodicBackgroundWorkerAdapter`1[TWorker]' violates the constraint of type parameter 'TWorker'.
Root cause as we read the 10.6 sources: BackgroundJobWorker no longer implements IBackgroundWorker in 10.6 (it is now IBackgroundJobWorker with its own timer), but the recurring job persisted in Hangfire SQL storage by earlier versions still references HangfirePeriodicBackgroundWorkerAdapter
Questions
- Is the 10.5.0/10.6.0 session invalidation on repeated re-authentication a known regression? If so, what is the fix/patch timeline, given no 10.5.x/10.6.x patch releases exist on the feed?
- Exactly where does IdentitySessionChecker resolve a SessionId — distributed cache, IIdentitySessionRepository, or both, and in what order? Is the lookup tenant-filtered? What conditions would make a just-created session invisible to it? Our environment: shared Redis across two slots, shared SQL DB, same user Id in all tenants.
- Did 10.5's single-active token provider change (or any other 10.5 identity change) alter the ordering of session creation vs revocation during a SignOut + SignIn executed in the same request pipeline (LinkUsers switch)? That matches our failure pattern exactly.
- Is there a supported configuration to relax or disable IdentitySessionChecker validation (keeping cookie auth working) as a TEMPORARY mitigation while this is investigated, and what are the security implications of doing so?
- Is the concurrency exception during the failing sequence (AbpDbConcurrencyException, "expected to affect 1 row(s), but actually affected 0 row(s)") a plausible cause of the lost session row, or a known benign symptom?
- Hangfire on 10.6: is RecurringJob.RemoveIfExists("HangfirePeriodicBackgroundWorkerAdapter
- If you cannot reproduce: which log categories at Debug level (e.g., Volo.Abp.Identity.Session, dynamic claims, token providers) and which additional captures (AbpSessions table snapshots, Redis keys) would you want from us? We can reproduce on demand within minutes.
We are staying on 10.4.0 (fully stable for us) until this is resolved.
5 Answer(s)
-
0
Hi,
This is a regression in the account switching flow: the previous session is now revoked during the switch, so any request the browser still has in flight with the old cookie signs itself out and clears the authentication cookie that the switch has just issued.
Until we ship the fix, you can skip the session revocation for the switch request. Add this to the
ConfigureServicesmethod of your*WebModule:context.Services.ConfigureApplicationCookie(options => { var previousOnSigningOut = options.Events.OnSigningOut; options.Events.OnSigningOut = async signingOutContext => { if (signingOutContext.HttpContext.Request.Path.StartsWithSegments("/Account/LinkLogin")) { return; } await previousOnSigningOut(signingOutContext); }; });This brings the switch flow back to the 10.4 behavior, where the previous session is kept instead of being revoked. We're tracking the
AbpDbConcurrencyExceptionseparately.For the Hangfire error on 10.6:
RecurringJob.RemoveIfExists("HangfirePeriodicBackgroundWorkerAdapter<BackgroundJobWorker>.DoWorkAsync")is the correct cleanup for the stale recurring job persisted by the earlier versions.We'll fix the account switching issue in the next release and add the Hangfire cleanup step to the migration guide. Your ticket has been refunded.
Thanks
Markdown supported.Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post) -
0
OK. should I delete these fixes once I upgrade to 10.7? I have already implemented
Add this to the ConfigureServices method of your *WebModule:
context.Services.ConfigureApplicationCookie(options => { var previousOnSigningOut = options.Events.OnSigningOut; options.Events.OnSigningOut = async signingOutContext => { if (signingOutContext.HttpContext.Request.Path.StartsWithSegments("/Account/LinkLogin")) { return; }
await previousOnSigningOut(signingOutContext); };}); This brings the switch flow back to the 10.4 behavior, where the previous session is kept instead of being revoked. We're tracking the AbpDbConcurrencyException separately.
For the Hangfire error on 10.6: RecurringJob.RemoveIfExists("HangfirePeriodicBackgroundWorkerAdapter<BackgroundJobWorker>.DoWorkAsync") is the correct cleanup for the stale recurring job persisted by the earlier versions.
Markdown supported.Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post) -
0
Hi,
Yes, remove the
ConfigureApplicationCookieworkaround for/Account/LinkLoginafter upgrading to 10.7.The complete fix is covered by https://github.com/abpframework/abp/pull/26028 and https://github.com/abpframework/abp/pull/26017. Keeping the workaround would prevent the previous session from being revoked correctly.
Thanks
Markdown supported.Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)
