Create new test projects in your existing solution (same naming convention ABP uses):
YourCompany.YourProject.TestBaseYourCompany.YourProject.Domain.TestsYourCompany.YourProject.Application.TestsYourCompany.YourProject.EntityFrameworkCore.Tests (or MongoDB.Tests if applicable)YourCompany.YourProject.Web.Tests (if you have a Web UI / host to integration-test)Reference the right layers (typical pattern)
*.Domain.Tests references:
*.Domain*.TestBase*.Application.Tests references:
*.Application*.TestBase*.EntityFrameworkCore.Tests references:
*.EntityFrameworkCore*.Application.Tests (so it can “implement” abstract tests against a real EF Core provider)*.Web.Tests references:
*.Web (or your host/UI project)*.Application.Tests*.EntityFrameworkCore.TestsFollow ABP’s current recommended test structure
Domain.Tests / Application.Tests as abstract base tests, then create concrete implementations in EntityFrameworkCore.Tests (or MongoDB.Tests) so tests are less coupled to the DB provider.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.
Please contact us at https://abp.io/contact
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.
The ID2083 error means OpenIddict is seeing the incoming request as HTTP, not HTTPS. In a Docker + reverse-proxy setup (TLS terminated at the proxy), this typically happens when the proxy doesn’t forward X-Forwarded-Proto: https (or ASP.NET Core is not allowed to trust/process it early enough).
Apply the OpenIddict behind load balancer configuration exactly (note: UseForwardedHeaders() must run before the rest of the pipeline that relies on scheme/host):
// In your IdpModule (or HttpApiHost module where OpenIddict runs)
public override void ConfigureServices(ServiceConfigurationContext context)
{
Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders =
ForwardedHeaders.XForwardedFor |
ForwardedHeaders.XForwardedProto;
});
}
public override void OnApplicationInitialization(ApplicationInitializationContext context)
{
var app = context.GetApplicationBuilder();
var env = context.GetEnvironment();
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
// Must be early
app.UseForwardedHeaders();
// If your proxy cannot forward headers correctly, force https scheme:
// (put this BEFORE OpenIddict endpoints are hit)
// app.Use((httpContext, next) =>
// {
// httpContext.Request.Scheme = "https";
// return next();
// });
// ...rest of pipeline
}
X-Forwarded-Proto: httpsX-Forwarded-For: <client-ip>HostOnce the app correctly sees the request scheme as https, /.well-known/openid-configuration will stop returning invalid_request / ID2083.
Links (validated):
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.
I can’t confirm (from any verified ABP 10.7 / LeptonX 5.7 source) that ABP officially supports keeping bootstrap-datepicker@1.10.1, timeago@1.6.7, and jquery-validation-unobtrusive@4.0.0 unchanged while moving the MVC bundle baseline to jQuery 4, despite those packages declaring <4 ranges.
In the verified materials available to me, there is no explicit engineer statement / doc that says “these range mismatches are expected and supported” for ABP 10.7 + LeptonX 5.7.
What can be stated definitively and consistently (based on your observed runtime behavior and ABP’s own declared dependency direction):
jquery-migrate@4.x, because migrate 4 requires jQuery 4 (your runtime error is the expected outcome of the mismatch).<4 ranges while also pulling jQuery 4, then that is an upstream dependency inconsistency that needs an official fix or an official override recommendation from ABP/LeptonX engineering—and I cannot provide that fix/override from verified sources.Because you asked for an “engineer confirmation” / “exact supported package versions or official override”: I don’t have a verified ABP source that provides that confirmation or the override matrix for ABP 10.7 / LeptonX 5.7.0. Therefore I can’t assert supportability of those mismatched ranges.
Practical next step (still self-contained, but noting the limitation above):
If you want a supported answer (not a workaround), this needs to be handled as an ABP support ticket / issue with your yarn.lock (or pnpm-lock.yaml) and the exact dependency tree output showing how those packages are being pulled under @volo/account@10.7.0 + @volo/abp.aspnetcore.mvc.ui.theme.leptonx@5.7.0. ABP can then either:
@abp/*) to versions whose peer ranges match jQuery 4, orSources (validated)
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.
Remove the old Yarn resolution and move to jQuery 4.x (with jquery-migrate 4.x) for an ABP 10.7 / LeptonX 5.7 MVC host.
~4.0.0 is ABP’s own signal that the supported baseline for ABP 10.7 MVC bundles is aligned with jQuery 4 (not jQuery 3).Do not try to “force” ABP 10.7’s MVC bundle to stay on jQuery 3.7.1 by pinning/resolutions while keeping ABP 10.7 packages:
About the “older bundled plugins” with jQuery <4 ranges (bootstrap-datepicker, timeago, etc.)
Recommended “supported” configuration for ABP 10.7 / LeptonX 5.7 (MVC host)
resolutions/pins that force jQuery 3.7.1.@abp/jquery can bring in the intended jQuery ~4.0.0 baseline.Browser flows to exercise (qualification checklist)
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.
app.InitializeApplicationAsync() (i.e., before Kestrel starts listening).Volo.Abp.EventBus.Azure / AbpEventBusAzureModule, and that microservice startup can be sensitive to infrastructure availability.Ensure Kubernetes, not your app, is responsible for retrying cold starts
startupProbe to allow long cold starts.Fail-fast the Azure Service Bus connectivity at startup (so you get an error instead of a silent hang)
InitializeApplicationAsync() and log exceptions. Example pattern:
ServiceBusAdministrationClient and call a lightweight operation (e.g., get topic/subscription properties) with your own cancellation/timeout.Add ABP module lifecycle logging around Azure event bus module
IModuleLifecycleContributor approach you already started and log start/end timestamps for each module initialization step. This is the most direct way to prove exactly where it blocks (and whether it’s always the Azure event bus module).Validate Azure Service Bus prerequisites that commonly cause long waits Even when entities exist, first-start hangs are often caused by infra-level issues that don’t immediately throw:
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.
InitializeApplicationAsync() runs ABP’s module lifecycle (OnPreApplicationInitialization / OnApplicationInitialization / OnPostApplicationInitialization) before Kestrel starts listening. So any module that does I/O (DB/network) during these phases can block the process from becoming “ready”.Volo.Abp.EventBus.Azure that would explain a ~120s hang only on first start, nor a documented/official way to “defer Azure Event Bus consumer start until after listening” for 10.0.x. So I can’t definitively confirm (1), (2), or (3) as written.Practical guidance that is consistent with ABP’s documented microservice startup approach (and matches your observed “second start succeeds” pattern):
Treat the first-start dependency wait as normal and let Kubernetes handle it
startupProbe / readinessProbe / livenessProbe grace periods so the pod isn’t killed by your own 120s deadline while ABP is still initializing.Focus diagnostics on “which module is blocking initialization”
InitializeApplicationAsync(), instrumenting module lifecycle (as you started doing with an IModuleLifecycleContributor logger) is the correct direction.Most likely blocking categories during ABP initialization (generic, but common in microservices)
OnApplicationInitialization / OnPostApplicationInitialization (including “check migrations”, seed data, etc.).Upgrade guidance
Sources (validated):
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.
Yes — with “Prevent concurrent login = Logout from all devices”, the expected behavior is:
So you can log in in a different browser, but the older browser session should be kicked out. That “falls back to login screen” you see on the older session is exactly what this setting is for.
If you mean: “Browser B login attempt immediately fails and you can’t complete login at all”, then that would not match “Logout from all devices”; that would be closer to a “block new login” behavior. But from what you shared (sessions table now updating and the UI going back to login), it looks like ABP is doing the correct “kick old session” behavior.
Also note (as already mentioned in the thread): saving the setting does not retroactively delete/affect existing sessions. It is applied when a new session is created (next login), which is why you only started seeing updates after re-saving and re-logging in.
(Verified behavior description is documented here:)
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.
In ABP 10.0.2, the “Prevent concurrent login = Logout from all devices” behavior does not continuously delete rows from AbpSessions. What it does is: when a new session is created, ABP marks the previous sessions as signed-out/invalid so they can no longer be used. Old rows can remain for history/auditing; that’s expected.
If your AbpSessions rows are not getting updated (e.g., SignedIn not changing / old sessions still usable), then in practice the usual root cause is: the Identity Session validation is not being executed on requests, so old sessions never get invalidated/checked.
app.UseAuthentication();
app.UseAbpDynamicClaims(); // must be between Authentication and Authorization
app.UseAuthorization();
Also ensure Dynamic Claims is enabled (your screenshot suggests it is, but the middleware must also run).
Verify session invalidation by behavior, not by “row count” Reproduce with the same user/tenant in two browsers:
If you use /connect/token flows heavily (Angular, separated AuthServer)
There is a known class of issues where the session row may not be committed/visible immediately when the token response is returned, which can break session checks on immediate next requests in some setups. Newer ABP versions include fixes for /connect commit timing; on 10.0.2, upgrading is the definitive fix path if you hit this.
Enable debug logs to confirm what is happening Turn on debug logs on AuthServer and HttpApi.Host, reproduce the 2-logins + API call scenario, and check for logs from the session checker/dynamic claims pipeline (this will confirm whether session validation is running at all).
(Guide)
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.
On Apple Silicon (M4/arm64), the most common reason an ABP API container crashes right after run-docker.ps1 is that the image was built for linux/amd64 but Docker is trying to run it as linux/arm64 (or the opposite). In that case the container typically fails immediately with an “exec format” / wrong-architecture type of startup error.
Fix: force the API (and DbMigrator) images to build for arm64, or run them explicitly as amd64 with emulation. Pick one approach and apply it consistently to all your .NET containers.
docker buildx create --use --name abp
docker buildx inspect --bootstrap
Update your build script (or run manual builds) to include:
--platform linux/arm64Example manual build:
docker buildx build --platform linux/arm64 -f Dockerfile.local -t nicma/idp-api:latest .
run-docker.ps1.If you must use amd64 images, set the platform in docker-compose.yml for each .NET service:
services:
idp-api-container:
platform: linux/amd64
db-migrator:
platform: linux/amd64
Then run again.
etc/build/build-images-locally.ps1 to build imagesetc/docker/run-docker.ps1 to run them (and generate dev HTTPS certs)If the scripts currently build amd64 by default on your machine, you’ll need to adjust them (or the compose) using one of the platform approaches above.
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.
