[Performance] Default Blazor Server template includes IntrospectAccessToken() which is redundant with UseDynamicClaims() — causes ~50 extra HTTP calls per page load

Summary

The default tiered Blazor Server project template includes options.IntrospectAccessToken() in the cookie authentication configuration. This causes an HTTP POST to the AuthServer's /connect/introspect endpoint for every HTTP request — including static assets (CSS, JS, images), SignalR negotiation, and _blazor calls.

When UseDynamicClaims() + IsDynamicClaimsEnabled = true are also configured (which they are by default in the same template), session validation is already handled via Redis/DB by IdentitySessionDynamicClaimsPrincipalContributor. The introspection is completely redundant.

The result is ~50 unnecessary HTTP POST calls to the AuthServer after login, adding 5–8 seconds of latency to the first page load.

Current behavior (default template)

// Generated by ABP template in BlazorModule.cs (tiered Blazor Server)
context.Services.AddAuthentication(options =>
{
    options.DefaultScheme = "Cookies";
    options.DefaultChallengeScheme = "oidc";
})
    .AddCookie("Cookies", options =>
    {
        options.ExpireTimeSpan = TimeSpan.FromDays(365);
        options.IntrospectAccessToken(); // ❌ Causes HTTP POST per request
    })
    .AddAbpOpenIdConnect("oidc", options => { ... });

// Also in the same template:
context.Services.Configure<AbpClaimsPrincipalFactoryOptions>(options =>
{
    options.IsDynamicClaimsEnabled = true; // ✅ Already validates sessions
});

// In OnApplicationInitialization:
app.UseDynamicClaims(); // ✅ Already validates sessions via Redis/DB

What happens on every request

With IntrospectAccessToken() enabled, after the user authenticates:

[Browser] GET /css/styles.css
  → [Blazor Server] POST /connect/introspect → [AuthServer]  ~50-200ms
  ← 200 OK (token is active)
  ← serves CSS

[Browser] GET /js/app.js
  → [Blazor Server] POST /connect/introspect → [AuthServer]  ~50-200ms
  ← 200 OK (token is active)
  ← serves JS

[Browser] POST /_blazor/negotiate
  → [Blazor Server] POST /connect/introspect → [AuthServer]  ~50-200ms
  ...

(repeated ~50 times for all resources loaded during page initialization)

Two redundant session validation mechanisms

The default template configures both mechanisms, but only one is needed:

| Mechanism | Cost per request | Session revocation | Source | |-----------|-----------------|-------------------|--------| | IntrospectAccessToken() | HTTP POST to AuthServer (50–200ms) | Yes | Cookie middleware | | UseDynamicClaims() + IsDynamicClaimsEnabled | Redis/DB lookup (<1ms) | Yes | IdentitySessionDynamicClaimsPrincipalContributor |

IdentitySessionDynamicClaimsPrincipalContributor (part of UseDynamicClaims()) validates the session on every request by checking the session ID in Redis/distributed cache. If an admin revokes a session (e.g., via Identity Management → Users → Sessions), the user is logged out on the next request — exactly the same behavior as IntrospectAccessToken(), but using a local Redis lookup instead of an HTTP round-trip to the AuthServer.

Measured impact

Tested on a Blazor Server tiered application (ABP 10.0.0 Commercial, .NET 10, localhost).

Post-login page load

| Metric | With IntrospectAccessToken | Without IntrospectAccessToken | Improvement | |--------|---------------------------|-------------------------------|-------------| | Introspection calls | ~50 POST requests | 0 | -100% | | AuthServer load | ~50 requests/page load | 0 | -100% | | Post-login page load time | ~8 seconds | ~2 seconds | ~6 seconds faster |

Why the impact is so large

1. No static file exclusion: The cookie authentication middleware runs for ALL requests, including static files. IntrospectAccessToken() adds an HTTP call to each one.
2. Blazor Server is request-heavy: A single page load involves CSS, JS, images, fonts, _blazor/negotiate, SignalR WebSocket upgrade, and multiple _blazor framework calls — easily 50+ requests.
3. Serial bottleneck: Many of these requests happen concurrently, creating a burst of ~50 simultaneous introspection calls against the AuthServer.
4. Latency compounds: Even at 50ms per introspection on localhost, 50 calls × 50ms = 2.5 seconds of added AuthServer processing time, causing request queuing and slower responses.

Proposed fix

Remove IntrospectAccessToken() from the default Blazor Server tiered template, since UseDynamicClaims() + IsDynamicClaimsEnabled = true already provide session validation:

.AddCookie("Cookies", options =>
{
    options.ExpireTimeSpan = TimeSpan.FromDays(365);
    // IntrospectAccessToken() removed — session validation is handled by
    // UseDynamicClaims() + IsDynamicClaimsEnabled via IdentitySessionDynamicClaimsPrincipalContributor
})

If IntrospectAccessToken() is intentionally kept for scenarios where UseDynamicClaims() is not enabled, consider:

1. Documenting the interaction between the two mechanisms so users understand they're redundant
2. Conditionally including IntrospectAccessToken() only when IsDynamicClaimsEnabled is false
3. At minimum: excluding static files from introspection (e.g., by path prefix)

Why removing it is safe

1. Session revocation still works: IdentitySessionDynamicClaimsPrincipalContributor checks session validity in Redis/DB on every request. Revoked sessions are detected immediately.

2. Token validation still works: The HttpApi.Host validates JWT tokens locally with AddAbpJwtBearer(). The Blazor Server app sends the access token in API calls, and the API host validates it without needing introspection.

3. The AuthServer uses UseLocalServer(): It validates its own tokens locally, not via introspection.

4. No behavioral change for users: Login, logout, session timeout, and session revocation all work identically. The only difference is the elimination of redundant HTTP calls.

Verification steps

After removing IntrospectAccessToken():

1. Login → verify access to protected pages works normally
2. Check AuthServer logs → confirm zero /connect/introspect requests from Blazor
3. Revoke a session via Identity Management → Users → Sessions → verify the user is logged out on next request (proves UseDynamicClaims() handles it)
4. Measure post-login page load time → confirm ~5-8 second improvement
5. Let the cookie expire → verify re-authentication is triggered normally

Affected scenarios

• Tiered Blazor Server — severely affected (50+ introspection calls per page load)
• Tiered MVC — also affected (fewer requests per page load, but still impacted)
• Non-tiered / monolith — not affected (no remote introspection endpoint)

Workaround

Remove the IntrospectAccessToken() call from the Blazor module:

.AddCookie("Cookies", options =>
{
    options.ExpireTimeSpan = TimeSpan.FromDays(365);
    // options.IntrospectAccessToken(); // Remove this line
})

Ensure UseDynamicClaims() and IsDynamicClaimsEnabled = true remain configured (they are by default).

Environment

• ABP Framework version: 10.0.0
• ABP Commercial version: 10.0.0
• .NET version: 10.0
• Hosting: Blazor Server (tiered architecture)
• Template: Default ABP Commercial Blazor Server (tiered)

[Performance] MvcCachedApplicationConfigurationClient fetches configuration and localization sequentially — easy ~400ms savings on cold cache

Summary

MvcCachedApplicationConfigurationClient.GetRemoteConfigurationAsync() fetches application-configuration and application-localization sequentially, but they can safely run in parallel. The localization call depends on a culture name that is already available from CultureInfo.CurrentCulture (set by ABP's RequestLocalizationMiddleware) — it does not need to wait for the configuration response.

This is a low-risk, high-impact optimization for all tiered Blazor Server deployments.

Current behavior (sequential)

[Request starts]
  → GET /api/abp/application-configuration    ~120ms
  ← Response received
  → GET /api/abp/application-localization      ~200ms  (waits for config to finish)
  ← Response received
[Total: ~320ms]

The sequential dependency exists because the current code extracts cultureName from config.Localization.CurrentCulture.Name before calling the localization endpoint:

// Current implementation in MvcCachedApplicationConfigurationClient
private async Task<ApplicationConfigurationDto> GetRemoteConfigurationAsync()
{
    var config = await ApplicationConfigurationAppService.GetAsync(
        new ApplicationConfigurationRequestOptions { IncludeLocalizationResources = false }
    );

    // ❌ Waits for config just to get cultureName
    config.Localization.Resources = (await ApplicationLocalizationClientProxy.GetAsync(
        new ApplicationLocalizationRequestDto
        {
            CultureName = config.Localization.CurrentCulture.Name,
            OnlyDynamics = true
        }
    )).Resources;

    return config;
}

Proposed behavior (parallel)

[Request starts]
  → GET /api/abp/application-configuration    ~120ms  (parallel)
  → GET /api/abp/application-localization      ~200ms  (parallel)
  ← Both responses received
[Total: ~200ms — savings: ~120ms per cache miss]

The key insight is that CultureInfo.CurrentCulture.Name is already set by ABP's RequestLocalizationMiddleware before MvcCachedApplicationConfigurationClient is invoked. It will always match config.Localization.CurrentCulture.Name, so we can use it directly without waiting for the configuration response:

// Proposed implementation
private async Task<ApplicationConfigurationDto> GetRemoteConfigurationAsync()
{
    // CultureInfo.CurrentCulture is already set by ABP's RequestLocalizationMiddleware
    var cultureName = CultureInfo.CurrentCulture.Name;

    var configTask = ApplicationConfigurationAppService.GetAsync(
        new ApplicationConfigurationRequestOptions { IncludeLocalizationResources = false }
    );

    var localizationTask = ApplicationLocalizationClientProxy.GetAsync(
        new ApplicationLocalizationRequestDto
        {
            CultureName = cultureName,
            OnlyDynamics = true
        }
    );

    await Task.WhenAll(configTask, localizationTask);

    var config = await configTask;
    config.Localization.Resources = (await localizationTask).Resources;

    return config;
}

Measured performance impact

Tested on a Blazor Server tiered application (ABP 10.0.0 Commercial, .NET 10, localhost).

Cold cache (first request after app start)

| Metric | Sequential (before) | Parallel (after) | Savings | |--------|---------------------|-------------------|---------| | application-configuration | 124ms | 117ms | — | | application-localization | 208ms | 237ms | — | | Total wall time | 332ms (sum) | 238ms (max) | ~94ms |

Warm cache miss (authenticated user, new cache key)

| Metric | Sequential (before) | Parallel (after) | Savings | |--------|---------------------|-------------------|---------| | application-configuration | 95ms | 116ms | — | | application-localization | 73ms | 120ms | — | | Total wall time | 168ms (sum) | 121ms (max) | ~47ms |

Note: In production environments with higher latency to the API host, the savings scale proportionally. If the shorter call takes 200ms in production, you save ~200ms per cache miss.

Impact per page load

Each page load triggers this on cache miss during both prerender and interactive phases. Savings compound:

• Cold start (no cache): ~120ms × 2 phases = ~240ms saved
• Warm cache miss (new user/session): ~50–120ms saved

Why this is safe

1. CultureInfo.CurrentCulture is guaranteed correct: ABP's RequestLocalizationMiddleware runs early in the pipeline and sets the culture before any application code executes. The MvcCachedApplicationConfigurationClient is invoked later (during Razor page rendering or Blazor circuit initialization), so the culture is already set.

2. No behavioral change: The localization endpoint receives the exact same CultureName — we're just reading it from a different (but equivalent) source.

3. No API contract change: Both endpoints are called with the same parameters as before.

4. Cache key unchanged: The distributed cache key generation (MvcCachedApplicationConfigurationClientHelper.CreateCacheKey) is not affected.

Affected scenarios

• Tiered Blazor Server — primary beneficiary (highest frequency of cache misses)
• Tiered MVC — also benefits
• Non-tiered / monolith — not affected (doesn't use MvcCachedApplicationConfigurationClient)

Workaround

Until this is addressed in ABP, applications can replace the service by implementing ICachedApplicationConfigurationClient directly with [Dependency(ReplaceServices = true)]:

[ExposeServices(typeof(ICachedApplicationConfigurationClient))]
[Dependency(ReplaceServices = true)]
public class ParallelCachedApplicationConfigurationClient
    : ICachedApplicationConfigurationClient, ITransientDependency
{
    // ... (full implementation available on request)
}

Important: The module containing this replacement must declare [DependsOn(typeof(AbpAspNetCoreMvcClientModule))] to ensure it loads after ABP's default registration.

Environment

• ABP Framework version: 10.0.0
• ABP Commercial version: 10.0.0
• .NET version: 10.0
• Hosting: Blazor Server (tiered architecture)
• Database: MongoDB (not relevant to this issue)

This ABP Suite issue is also reported as a request in https://abp.io/qa/questions/8803/3a18c029-e901-3c3a-86d9-0bc6255b445f. But I am reporting it as issue because I think it is important.

When creating a master - child entities, ABP suite is generating managers (DomainService) for master (AggregateRoot) and child (Entity) entities. This means child entities can be managed directly from child services (application and domain services) without using the master entity, and I think it is not DDD friendly. My suggestions for ABP Suite is:

• Do not create the manager (DomainService) for the child entity
• Create methods for managing child entities within the master managers (DomainService). In that way the DomainServices for the AggregateRoot entity will take care about its child entities being more DDD friendly.

We have a tiered solution created some months ago. There are 3 developers working on it and when 2 of them try to open the solution with ABP Suite, it's is failing. But it is working for one of them. This is the project structure (I do not see the option to get the solution configuration with ABP Studio, the button is not visible now): ABP Studio version is 1.0.2 ABP Suite version is 9.1.1, same as the solution. Below you can find the error and the workaround. We are reporting it in case there is an issue with ABP Suite reading the solution or something similar.

This is the error we found in ABP Suite logs when trying to open the solution without success:

2025-07-01 12:19:42.041 +02:00 [INF] Loaded ABP modules:
...
2025-07-01 12:19:43.137 +02:00 [INF] Now listening on: http://localhost:3000
...
2025-07-01 12:19:46.935 +02:00 [INF] Executing ContentResult with HTTP Response ContentType of application/javascript
2025-07-01 12:19:46.935 +02:00 [INF] Request finished HTTP/1.1 GET http://localhost:3000/Abp/ServiceProxyScript - 200 9386 application/javascript 419.1011ms
2025-07-01 12:19:46.936 +02:00 [DBG] Executed AbpApplicationConfigurationAppService.GetAsync().
2025-07-01 12:19:46.936 +02:00 [INF] Executed action Volo.Abp.AspNetCore.Mvc.Localization.AbpApplicationLocalizationScriptController.GetAsync (Volo.Abp.AspNetCore.Mvc) in 409.6628ms
2025-07-01 12:19:46.936 +02:00 [INF] Executed endpoint 'Volo.Abp.AspNetCore.Mvc.Localization.AbpApplicationLocalizationScriptController.GetAsync (Volo.Abp.AspNetCore.Mvc)'
2025-07-01 12:19:46.936 +02:00 [INF] Request finished HTTP/1.1 GET http://localhost:3000/Abp/ApplicationLocalizationScript?cultureName=en - 200 69286 application/javascript 422.0271ms
2025-07-01 12:19:46.963 +02:00 [WRN] The cookie 'XSRF-TOKEN' has set 'SameSite=None' and must also set 'Secure'.
2025-07-01 12:19:46.965 +02:00 [INF] Executing ContentResult with HTTP Response ContentType of application/javascript
2025-07-01 12:19:46.966 +02:00 [INF] Executed action Volo.Abp.AspNetCore.Mvc.ApplicationConfigurations.AbpApplicationConfigurationScriptController.Get (Volo.Abp.AspNetCore.Mvc) in 445.6118ms
2025-07-01 12:19:46.966 +02:00 [INF] Executed endpoint 'Volo.Abp.AspNetCore.Mvc.ApplicationConfigurations.AbpApplicationConfigurationScriptController.Get (Volo.Abp.AspNetCore.Mvc)'
2025-07-01 12:19:46.966 +02:00 [INF] Request finished HTTP/1.1 GET http://localhost:3000/Abp/ApplicationConfigurationScript - 200 2207 application/javascript 451.5745ms
2025-07-01 12:19:47.086 +02:00 [INF] Request starting HTTP/1.1 POST http://localhost:3000/api/abpSuite/addSolution - application/json 82
2025-07-01 12:19:47.090 +02:00 [INF] Executing endpoint 'Volo.Abp.Suite.Controllers.AbpSuiteController.AddSolutionAsync (Volo.Abp.Suite)'
2025-07-01 12:19:47.094 +02:00 [INF] Route matched with {action = "AddSolution", controller = "AbpSuite", area = "", page = ""}. Executing controller action with signature System.Threading.Tasks.Task`1[Volo.Abp.Suite.Models.Solution] AddSolutionAsync(Volo.Abp.Suite.Services.AddSolutionInput) on controller Volo.Abp.Suite.Controllers.AbpSuiteController (Volo.Abp.Suite).
2025-07-01 12:19:47.161 +02:00 [INF] Request starting HTTP/1.1 GET http://localhost:3000/libs/@fortawesome/fontawesome-free/webfonts/fa-regular-400.woff2 - null null
2025-07-01 12:19:47.162 +02:00 [INF] The file /libs/@fortawesome/fontawesome-free/webfonts/fa-regular-400.woff2 was not modified
2025-07-01 12:19:47.163 +02:00 [INF] Request finished HTTP/1.1 GET http://localhost:3000/libs/@fortawesome/fontawesome-free/webfonts/fa-regular-400.woff2 - 304 null font/woff2 1.5587ms
2025-07-01 12:19:47.185 +02:00 [INF] Received HTTP response headers after 252.7415ms - 200
2025-07-01 12:19:47.186 +02:00 [INF] End processing HTTP request after 271.0727ms - 200
2025-07-01 12:19:47.208 +02:00 [INF] Executing ObjectResult, writing value of type 'System.Boolean'.
2025-07-01 12:19:47.209 +02:00 [INF] Executed action Volo.Abp.Suite.Controllers.AbpSuiteController.IsSuiteOutDatedAsync (Volo.Abp.Suite) in 594.6038ms
2025-07-01 12:19:47.209 +02:00 [INF] Executed endpoint 'Volo.Abp.Suite.Controllers.AbpSuiteController.IsSuiteOutDatedAsync (Volo.Abp.Suite)'
2025-07-01 12:19:47.209 +02:00 [INF] Request finished HTTP/1.1 GET http://localhost:3000/api/abpSuite/is-suite-outdated - 200 null application/json; charset=utf-8 627.9899ms
2025-07-01 12:19:48.605 +02:00 [ERR] ---------- RemoteServiceErrorInfo ----------
{
  "code": null,
  "message": "An internal error occurred during your request!",
  "details": null,
  "data": null,
  "validationErrors": null
}

2025-07-01 12:19:48.609 +02:00 [ERR] Error getting value from 'MigrationsMigrationsDbContext' on 'Volo.Abp.Suite.Models.Solution'.
Newtonsoft.Json.JsonSerializationException: Error getting value from 'MigrationsMigrationsDbContext' on 'Volo.Abp.Suite.Models.Solution'.
 ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at Volo.Abp.Suite.Models.Solution.get_MigrationsMigrationsDbContext()
   at Newtonsoft.Json.Serialization.ExpressionValueProvider.GetValue(Object target)
   --- End of inner exception stack trace ---
   at Newtonsoft.Json.Serialization.ExpressionValueProvider.GetValue(Object target)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.CalculatePropertyValues(JsonWriter writer, Object value, JsonContainerContract contract, JsonProperty member, JsonProperty property, JsonContract& memberContract, Object& memberValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeValue(JsonWriter writer, Object value, JsonContract valueContract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeList(JsonWriter writer, IEnumerable values, JsonArrayContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeValue(JsonWriter writer, Object value, JsonContract valueContract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeObject(JsonWriter writer, Object value, JsonObjectContract contract, JsonProperty member, JsonContainerContract collectionContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.SerializeValue(JsonWriter writer, Object value, JsonContract valueContract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerProperty)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalWriter.Serialize(JsonWriter jsonWriter, Object value, Type objectType)
   at Newtonsoft.Json.JsonSerializer.SerializeInternal(JsonWriter jsonWriter, Object value, Type objectType)
   at Newtonsoft.Json.JsonSerializer.Serialize(JsonWriter jsonWriter, Object value, Type objectType)
   at Newtonsoft.Json.JsonConvert.SerializeObjectInternal(Object value, Type type, JsonSerializer jsonSerializer)
   at Newtonsoft.Json.JsonConvert.SerializeObject(Object value, Type type, Formatting formatting, JsonSerializerSettings settings)
   at Newtonsoft.Json.JsonConvert.SerializeObject(Object value, Formatting formatting, JsonSerializerSettings settings)
   at Newtonsoft.Json.JsonConvert.SerializeObject(Object value, Formatting formatting)
   at Volo.Abp.Suite.Areas.AbpSuite.CrudPageGenerator.Helpers.IoHelper.WriteObjectToFileAsync[T](String filePath, T obj, Formatting serializeFormat)
   at Volo.Abp.Suite.Services.PersistanceService.SaveAppSettingsAsync(AppSettings appSettings)
   at Volo.Abp.Suite.Services.PersistanceService.JyuRJXBu39(AddSolutionInput  )
   at Volo.Abp.Suite.Services.PersistanceService.AddSolutionAsync(AddSolutionInput input)
   at Volo.Abp.Suite.Controllers.AbpSuiteController.AddSolutionAsync(AddSolutionInput input)
   at lambda_method1880(Closure, Object)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.AwaitableObjectResultExecutor.Execute(ActionContext actionContext, IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Awaited|12_0(ControllerActionInvoker invoker, ValueTask`1 actionResultValueTask)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextExceptionFilterAsync>g__Awaited|26_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
2025-07-01 12:19:48.632 +02:00 [INF] Executing ObjectResult, writing value of type 'Volo.Abp.Http.RemoteServiceErrorResponse'.
2025-07-01 12:19:48.634 +02:00 [INF] Executed action Volo.Abp.Suite.Controllers.AbpSuiteController.AddSolutionAsync (Volo.Abp.Suite) in 1539.9778ms
2025-07-01 12:19:48.634 +02:00 [INF] Executed endpoint 'Volo.Abp.Suite.Controllers.AbpSuiteController.AddSolutionAsync (Volo.Abp.Suite)'
2025-07-01 12:19:48.634 +02:00 [INF] Request finished HTTP/1.1 POST http://localhost:3000/api/abpSuite/addSolution - 500 null application/json; charset=utf-8 1548.826ms

The workaround we found out is to modify the ABP Suite appsettings.json configuration. Once done, all developers could open the solution with ABP Suite again. First, we remove the configuration related to the project. Tried to open the solution again without success. Then we copy the following configuration (updating the paths accordingly to the local paths), and the solution could be opened.

    {
      "Id": "6d30d4ee-9166-4389-86ed-761acaa03b31",
      "Name": "Driven2u.Cpaas",
      "UiFramework": 5,
      "ProjectNameWithCompanyName": "Driven2u.Cpaas",
      "OnlyProjectName": "Cpaas",
      "Path": "C:\\repos\\driven2u\\cpaas\\Driven2u.Cpaas.sln",
      "RootProjectDirectory": "C:\\repos\\driven2u\\cpaas",
      "SrcFolderDirectory": "C:\\repos\\driven2u\\cpaas\\src",
      "TestFolderDirectory": "C:\\repos\\driven2u\\cpaas\\test",
      "IsMicroserviceNolayerProject": false,
      "NolayerProjectDirectory": null,
      "NolayerContractsProjectDirectory": null,
      "WebProjectDirectory": null,
      "DomainProjectDirectory": "C:\\repos\\driven2u\\cpaas\\src\\Driven2u.Cpaas.Domain",
      "DomainSharedProjectDirectory": "C:\\repos\\driven2u\\cpaas\\src\\Driven2u.Cpaas.Domain.Shared",
      "ApplicationProjectDirectory": "C:\\repos\\driven2u\\cpaas\\src\\Driven2u.Cpaas.Application",
      "ApplicationContractsProjectDirectory": "C:\\repos\\driven2u\\cpaas\\src\\Driven2u.Cpaas.Application.Contracts",
      "EntityFrameworkCoreProjectDirectory": null,
      "MongoDbProjectDirectory": "C:\\repos\\driven2u\\cpaas\\src\\Driven2u.Cpaas.MongoDB",
      "EntityFrameworkCoreDbMigrationsProjectDirectory": null,
      "MongoDbTestsProjectDirectory": "C:\\repos\\driven2u\\cpaas\\test\\Driven2u.Cpaas.MongoDB.Tests",
      "EntityFrameworkCoreTestsProjectDirectory": null,
      "DomainTestsProjectDirectory": "C:\\repos\\driven2u\\cpaas\\test\\Driven2u.Cpaas.Domain.Tests",
      "ApplicationTestsProjectDirectory": "C:\\repos\\driven2u\\cpaas\\test\\Driven2u.Cpaas.Application.Tests",
      "TestBaseProjectDirectory": "C:\\repos\\driven2u\\cpaas\\test\\Driven2u.Cpaas.TestBase",
      "MigratorProjectDirectory": "C:\\repos\\driven2u\\cpaas\\src\\Driven2u.Cpaas.DbMigrator",
      "MigratorCsprojFileName": "Driven2u.Cpaas.DbMigrator.csproj",
      "AngularSolutionRootPath": null,
      "DefaultNamespace": "Driven2u.Cpaas",
      "DefaultNamespaceAsCamelCase": "driven2u.cpaas",
      "MigrationsMigrationsDbContext": "CpaasDbContext",
      "TenantMigrationsMigrationsDbContext": "CpaasTenantDbContext",
      "DbContextFilePath": "C:\\repos\\driven2u\\cpaas\\src\\Driven2u.Cpaas.MongoDB\\MongoDb\\CpaasMongoDbContext.cs",
      "TenantDbContextFilePath": null,
      "DbContextModelCreatingExtensionsFilePath": "C:\\repos\\driven2u\\cpaas\\src\\Driven2u.Cpaas.MongoDB\\MongoDb\\CpaasMongoDbContext.cs",
      "HttpApiHostProjectDirectory": "C:\\repos\\driven2u\\cpaas\\src\\Driven2u.Cpaas.HttpApi.Host",
      "HttpApiProjectDirectory": "C:\\repos\\driven2u\\cpaas\\src\\Driven2u.Cpaas.HttpApi",
      "HttpApiClientProjectDirectory": "C:\\repos\\driven2u\\cpaas\\src\\Driven2u.Cpaas.HttpApi.Client",
      "BlazorProjectDirectory": "C:\\repos\\driven2u\\cpaas\\src\\Driven2u.Cpaas.Blazor",
      "MauiBlazorProjectDirectory": null,
      "BlazorWebAppProjectDirectory": null,
      "StartupProjectDirectory": "C:\\repos\\driven2u\\cpaas\\src\\Driven2u.Cpaas.HttpApi.Host",
      "StartupProjectName": "Driven2u.Cpaas.HttpApi.Host",
      "DatabaseProvider": 2,
      "DatabaseProviderName": "MongoDb",
      "UiFrameworkName": "BlazorServer",
      "ApplicationContractsExists": true,
      "MigratorProjectExists": true,
      "UpdateDatabaseMethod": 1,
      "IsTieredArchitecture": true,
      "ActiveDate": "2025-07-01T13:05:34.0123789+02:00",
      "ProjectTemplateType": 1,
      "AbpVersion": "9.1.1"
    }

Hi ABP team,

We have to pass SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing) tests. SAST analyzes the source code of the application to find flaws, while DAST examines a running application from an external perspective to detect vulnerabilities. Right now we only executed SAST tests and we saw some vulnerabilities related to the framework and deployment code. I am sharing those findings with you, hope it helps to enhance the framework security (note: rename the png file to html to see the report): Once we execute the DAST tests, I can share with you the results as well. This is the solution configuration:

• Template: app
• Created ABP Studio Version: 0.9.23
• Current ABP Studio Version: 0.9.25
• Tiered: Yes
• Multi-Tenancy: Yes
• UI Framework: blazor-server
• Theme: leptonx
• Theme Style: system
• Run Install Libs: Yes
• Database Provider: mongodb
• Run Db Migrator: Yes
• Mobile Framework: none
• Public Website: No
• Include Tests: Yes
• Kubernetes Configuration: Yes
• Distributed Event Bus: none
• Use Local References: No
• Optional Modules:
  • TextTemplateManagement
  • LanguageManagement
  • AuditLogging
  • OpenIddictAdmin