Activities of "LiSong"

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.

hi, how do I know if the fixes for these are released? should I just wait for 10.7? thanks

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)

1. Fresh cookie login on tenant A (admin user). Session works.
2. First re-auth: sign out, sign in under tenant B (same user Id exists there). Session works; pages render.
3. 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

1. 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?
2. 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.
3. 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.
4. 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?
5. 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?
6. Hangfire on 10.6: is RecurringJob.RemoveIfExists("HangfirePeriodicBackgroundWorkerAdapter
7. 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.

I found there are 4 ABP-owned workers: TokenCleanupBackgroundWorker IdentitySessionCleanupBackgroundWorker ExcelFileCleanupWorker ExpiredAuditLogDeleterWorker

I want to change all of them run nightly to make the system more stable.

1. 2 of them are running hourly now, is it ok to make them run daily?
2. how can I update their settings, I opened the hangfire admin page, but it seems it's readonly, correct?

thanks

We're seeing AppConnections (bound sockets metric) climb at ~120/minute during idle periods with zero incoming HTTP requests, peaking at 1,900+ before the worker process recycles. This eventually causes Win32 error 10055 (WSAENOBUFS — socket buffer exhaustion), which breaks outbound connections to SQL Server and Azure Blob Storage, App restart resets the count, then it starts climbing again immediately, At peak, new outbound connections fail with Win32Exception (10055): An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full

What we've tried: Removed Hangfire's SlidingInvisibilityTimeout Gave Hangfire a dedicated connection string with Max Pool Size=25 to isolate it from EF Core's pool

Questions:

1. Does ABP have any internal background processes (cache refresh, audit log flush, distributed lock renewal, tenant resolution polling) that open outbound connections independently of HTTP requests?
2. With IsDynamicClaimsEnabled = true and 16 tenants on a shared database, does ABP's SecurityStampValidator or MultiTenantConnectionStringResolver create connections on a timer?
3. Has anyone seen similar socket accumulation with ABP + Hangfire.SqlServer on Azure App Service?

Any guidance appreciated

in the host site, we didn't enable the File Management module, however, all tenants can see the Files in the left sidebar, why? how to fix it?

Impersonation works correctly (admin can log in as another user), but the “Back to my account” / “Back to admin” button no longer appears in the top toolbar, so we cannot revert easily. how to debug? thanks

I have implemented SSO in a Next.js site using ABP.io, but when I call the API endpoints, I get a 401. Is there any doc on how to call an endpoint with the SSO token? thanks

I created new applications under OpenID > Applications, and SSO is working correctly. For example, I can sign in to my Next.js application using abp.io accounts.

Now I’d like to update the flow so that when users click the SSO sign-in button from the Next.js application, the abp.io site automatically switches to a specific tenant—for example, the tenant “NextJs”—when the user lands on the /Account/Register page.

I noticed that the Next.js app invokes /connect/authorize?client_id=Next_app. So I’m wondering: can we add server-side logic in abp.io to automatically switch to the “NextJs” tenant when client_id equals Next_app?

Is this a good solution? If so, how should it be implemented? Or is there a better recommended approach for tenant resolution in this case?

but how can I use it here, or can you give me the full file? can't find the namespaces

*You can try to override the GetSelectedStyleAsync method of ILeptonXStyleProvider service always to return LeptonXStyleNames.Light?

public override Task<string> GetSelectedStyleAsync() { return Task.FromResult(LeptonXStyleNames.Light); } Thanks.*