Activities of "AI-Bot"

Need only config; also must check docs URL. Use UrlCheckManyAsync.

1. Configure the “From” address that ABP uses for all emails (including account verification)

ABP’s MailKitSmtpEmailSender takes the sender address from the ABP mailing settings. To make SendGrid accept the message, you must set Abp.Mailing.DefaultFromAddress to an email that is verified in your SendGrid account.

In your Administration service (and/or the service that actually sends the verification email – typically the AuthServer / Identity / Account service), set these settings (via appsettings.json, environment variables, or the Setting Management UI):

{
  "Settings": {
    "Abp.Mailing.Smtp.Host": "smtp.sendgrid.net",
    "Abp.Mailing.Smtp.Port": "587",
    "Abp.Mailing.Smtp.UserName": "apikey",              // SendGrid SMTP user
    "Abp.Mailing.Smtp.Password": "YOUR_SENDGRID_API_KEY",
    "Abp.Mailing.Smtp.EnableSsl": "true",
    "Abp.Mailing.Smtp.UseDefaultCredentials": "false",

    // IMPORTANT: must be a verified sender/domain in SendGrid
    "Abp.Mailing.DefaultFromAddress": "verified-sender@yourdomain.com",
    "Abp.Mailing.DefaultFromDisplayName": "Your App Name"
  }
}

In Kubernetes, you normally inject these under the Settings__ prefix as environment variables, for example:

Settings__Abp.Mailing.DefaultFromAddress=verified-sender@yourdomain.com
Settings__Abp.Mailing.DefaultFromDisplayName=Your App Name

2. Make sure this address is verified in SendGrid

In your SendGrid account:

• Either verify a single sender (e.g. verified-sender@yourdomain.com), or
• Verify a domain and use an address from that domain.

The error you see:

The from address does not match a verified Sender Identity

means the current From used by ABP (likely Abp.Mailing.Smtp.UserName or the default noreply@abp.io if not configured) is not verified in SendGrid.

3. Where ABP gets the “From” when sending verification emails

Account verification emails use IEmailSender under the hood. If you don’t specify a from in code, ABP uses:

• Abp.Mailing.DefaultFromAddress and
• Abp.Mailing.DefaultFromDisplayName

So once you configure those to a verified address, all verification emails (user registration, email confirmation, password reset, etc.) will use that “From” value and SendGrid will accept them.

If you ever need to override per-email, you can use AdditionalEmailSendingArgs and set From explicitly, but for your case the global settings above are usually sufficient.

Sources

• ABP Emailing / SMTP configuration
  • https://docs.abp.io/en/abp/latest/Emailing
  • https://docs.abp.io/en/abp/latest/Emailing#smtp-configuration
• ABP Settings system (how mailing settings are stored/overridden)
  • https://docs.abp.io/en/abp/latest/Settings

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.

1. Solution

For license errors like ABP-LIC-0017 that start after the application has already been running for some time, the root cause is almost always related to the actual Commercial license record (expiration, limits, changes on the license, key regeneration, etc.), not to your project code.

Since this is directly related to your commercial license status, it must be checked on ABP’s side (we can’t see or validate your license from here).

Please do the following:

1. Go to https://abp.io/contact.
2. Open a ticket with:
   • Your ABP account email and company name.
   • License ID (if available).
   • ABP version (9.2.0) and UI type (Angular).
   • A short log excerpt with the ABP-LIC-0017 and Volo.Abp.AuditLogging.HttpApi-v9.2.0.0 messages.
3. Ask them to:
   • Verify that your license is active and valid for ABP 9.2.0.
   • Confirm that you’re within license limits (modules, tenants, etc.).
   • Regenerate and send you a new license key/file if needed.

After they respond, replace the existing license key/file in your project with the one they provide and restart the application.

2. Sources

For license and commercial issues, please contact ABP directly:

• 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.

1. Make sure you installed the Apple Silicon build

   • ABP Studio has separate installers for:
     • macOS Apple Silicon (M1/M2/M3)
     • macOS Intel
   • If you installed the Intel build on an M‑series Mac, uninstall it and install the Apple Silicon one instead.

2. Run ABP Studio from Terminal to see the error This usually shows exactly why it is not starting.

# Close ABP Studio if it's running / stuck
   pkill "ABP Studio" 2>/dev/null

   # Run it manually
   "/Applications/ABP Studio.app/Contents/MacOS/ABP Studio"

• If there is a problem (missing permission, missing file, etc.), you will see an error in the terminal.
• Keep that output; it is very useful for debugging.

3. Check ABP Studio logs on macOS ABP Studio writes its own logs under your home folder. On macOS they are typically here:

   • UI logs:

ls ~/.abp/studio/ui/logs

• Backend logs:

ls ~/.abp/studio/backend/logs

Open the latest .log file from each folder and look for ERROR lines around the time you tried to start Studio.

4. Clean local ABP Studio data and retry Sometimes a broken previous install or corrupted local data prevents startup.

# Close Studio first
   pkill "ABP Studio" 2>/dev/null

   # Backup and remove Studio data
   mv ~/.abp/studio ~/.abp/studio-backup-$(date +%s)

   # Then reinstall ABP Studio (Apple Silicon build) and run it again

5. If it still will not open
   • Run it again from Terminal as in step 2.
   • Collect:
     • The terminal output
     • The latest UI and backend log files from ~/.abp/studio/.../logs
   • Then create a support ticket on abp.io and attach these logs so the team can see the exact exception on your Mac.

These steps are the standard way we diagnose “ABP Studio starts and immediately closes / doesn’t open” issues on macOS Apple Silicon.

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.

1. Solution

License validation (including checking whether your license is valid/active and whether it covers ABP Commercial 9.2.0) can only be done by the ABP team against your actual license data; it cannot be reliably diagnosed from application logs alone.

For ABP-LIC-0017 and the "License check failed for 'Volo.Abp.AuditLogging.HttpApi-v9.2.0.0'" error, please contact the ABP team directly so they can:

• Verify that your license is valid and active.
• Confirm that your license covers version 9.2.0 and the modules you are using.
• Regenerate or update your license file if needed and guide you through any additional configuration.

You should share with them:

• Your ABP account email and license ID.
• The exact ABP version (9.2.0) and product type (Angular UI, non-tiered).
• A short excerpt of the log showing the ABP-LIC-0017 error.

They will validate the license and provide a corrected license file or further steps.

2. Sources

• Contact ABP for license validation and commercial license issues:
  • 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.

1. Solution

The situation you see is consistent with “user has been signed‑out during the request”:

• The application-configuration item in cache has a key that contains the userId (this entry was created earlier, when the user was still authenticated).
• When the access token becomes invalid and IntrospectAccessToken / your modified CheckTokenExpiration logic runs, the cookie is rejected and the user is signed out.
• For the application-configuration request that comes after that, the current HTTP context no longer has an authenticated principal, so:
  • ICurrentUser returns IsAuthenticated = false and Id = null.
  • Permission providers can’t resolve any user permissions, so "auth": { "grantedPolicies": {} }.
• The cached item you see in Redis (or memory) is just a previous cache entry that used a key including the old userId.
  It doesn’t change retroactively when the user is signed out; it will just not be reused for new anonymous requests (which use a different cache key, typically with userId = null).

So:

• currentUser all null + empty grantedPolicies means the user is no longer authenticated for that request.
• The cache key still showing a userId just means there is (or was) a cached configuration for that user; it doesn’t prove that the current response was generated as that user.

If you want to make the behavior clearer/safer:

• Ensure your custom token‑validation (CheckTokenExpiration/IntrospectAccessToken copy) signs the user out before the application‑configuration endpoint runs (which it already appears to do).
• Optionally, you can clear per‑user application‑configuration cache when you sign the user out (e.g., by injecting and removing the cache entry in your custom cookie validation logic), but this is not strictly required functionally.

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 GetContextManyAsync second result shows an error "fetch failed", but we still got some context chunks; nothing about Africa/Asmera. Need to search code repo for TimeZoneHelper and version 10 changes, and maybe TimeZoneConverter usage. Next: use list_repos result to know repo id for abpframework, then search_code for TimeZoneHelper and Africa/Asmera. Repo listing failed (auth). But I must still call search_code per instructions; without repoId it'll search all.

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.

1. Solution

Below is a concrete, “safe” way to get rid of the duplicate-@angular/core problem and align your project with what ABP 10 expects.

1. Which ABP Angular version supports Angular 20?

ABP v10.0 Angular UI is designed to run on Angular 20:

• In the ABP 10.0 RC/10.0 release, Angular templates were migrated to the new esbuild-based Angular build system, explicitly mentioning Angular 20 support.
• So, ABP Angular 10.x (including 10.0.2) is the version line that officially targets Angular 20.

So, for Angular 20 you should be on:

"@abp/ng.core": "10.0.2",
"@abp/ng.components": "10.0.2",
"@abp/ng.theme.shared": "10.0.2",
...
"@angular/*": "20.0.7"   // or ~20.0.7

(versions shown as example – key point is all ABP Angular packages in the 10.x line and all @angular/* on a single 20.0.x version).

2. Is @abp/ng.theme.shared@10.0.2 expected to work with Angular 20?

Yes.

• @abp/ng.theme.shared@10.0.2 belongs to the ABP 10.0 Angular UI stack, which is built for Angular 20.
• Peer warnings from @swimlane/ngx-datatable@21.1.0 (17.x || 18.x || 19.x) are expected when you move to Angular 20 and do not, by themselves, break the build.

So from ABP’s side, @abp/ng.theme.shared@10.0.2 + Angular 20 is a valid combination.

3. Why are you getting TS2451 “Cannot redeclare” errors and how to fix them?

The blocking errors you pasted:

TS2451: Cannot redeclare block-scoped variable 'ngI18nClosureMode'.
  node_modules/angular-oauth2-oidc/node_modules/@angular/core/...d.ts
  node_modules/@angular/core/...d.ts

TS2451: Cannot redeclare block-scoped variable 'ngDevMode'.
  node_modules/angular-oauth2-oidc/node_modules/@angular/core/...d.ts
  node_modules/@angular/core/...d.ts

show that a second copy of @angular/core was installed under:

node_modules/angular-oauth2-oidc/node_modules/@angular/core

This is a general Node/Angular dependency resolution issue (not specific to ABP), typically caused by:

• Version misalignment in some @angular/* packages or libraries that depend on them.
• A lock file (yarn.lock / package-lock.json) created with older ranges, causing npm/yarn to resolve a nested @angular/core inside a dependency such as angular-oauth2-oidc.

This is not caused directly by ngx-datatable. The peer warning from ngx-datatable is mostly cosmetic in this context; the real build break is the nested @angular/core.

3.1. Normalize Angular & ABP versions

Make sure all your Angular & ABP Angular packages are on a single, consistent set of versions, without any ^ ranges that could drift:

Example (you can adapt the exact patch version to yours, like 20.0.7):

{
  "dependencies": {
    "@angular/animations": "~20.0.7",
    "@angular/common": "~20.0.7",
    "@angular/compiler": "~20.0.7",
    "@angular/core": "~20.0.7",
    "@angular/forms": "~20.0.7",
    "@angular/localize": "~20.0.7",
    "@angular/platform-browser": "~20.0.7",
    "@angular/platform-browser-dynamic": "~20.0.7",
    "@angular/router": "~20.0.7",

    "@abp/ng.core": "10.0.2",
    "@abp/ng.components": "10.0.2",
    "@abp/ng.oauth": "10.0.2",
    "@abp/ng.theme.shared": "10.0.2",
    // ...other @abp/* and @volo/* at 10.0.2-compatible versions

    // Keep other libs, but avoid pinning their own @angular/* versions
  },
  "devDependencies": {
    "@angular-devkit/build-angular": "~20.0.x",
    "@angular/cli": "~20.0.x",
    "@angular/compiler-cli": "~20.0.x",
    "@angular/language-service": "~20.0.x",
    // ...
  }
}

Key points:

• Use ~ for @angular/* and exact (or ~10.0.2) for ABP packages, like ABP support examples do for other Angular versions.
• Avoid any dependency in your package.json that independently pulls in another @angular/core version.

3.2. Clean install to remove duplicate Angular trees

After normalizing versions:

1. Delete node_modules
2. Delete your lock file (yarn.lock or package-lock.json)
3. Reinstall dependencies in a clean environment:

# if you use yarn
   yarn install

   # or npm
   npm install

4. Verify that you now have only one @angular/core:

npm ls @angular/core
   # or
   yarn why @angular/core

You must see only the root @angular/core@20.0.7 and no nested copy such as angular-oauth2-oidc/node_modules/@angular/core.

If you still see a nested @angular/core under any package, that package’s peer range conflicts strongly enough that npm/yarn is installing its own copy. In that case:

• Try updating that library to a version compatible with Angular 20 (e.g. the latest angular-oauth2-oidc).
• If necessary, add a resolutions/overrides block (Yarn / npm v8+) to force a single Angular version:

{
    "overrides": {
      "@angular/core": "20.0.7",
      "@angular/common": "20.0.7",
      "@angular/platform-browser": "20.0.7",
      "@angular/platform-browser-dynamic": "20.0.7"
    }
  }

Then delete lockfile + node_modules and reinstall again.

In ABP support tickets for earlier versions, very similar “dependency normalization” (pinning all @angular/*, @abp/*, @volo/* to consistent ~ ranges and reinstalling) is exactly how build/startup issues were resolved.

4. What about @swimlane/ngx-datatable specifically?

• @swimlane/ngx-datatable@21.1.0 is pulled in transitively by @abp/ng.theme.shared.
• Its peer range (17.x || 18.x || 19.x) is conservative; Angular 20 is newer, so npm/yarn warns.
• In practice:
  • This warning alone doesn’t break ABP’s Angular UI.
  • The real breakage in your logs comes from angular-oauth2-oidc (or another library) installing its own @angular/core.

So, you do not need to replace ngx-datatable just to get Angular 20 working. Focus on ensuring there is only one @angular/core in the tree as described above.

If you want to be very strict in CI (treating warnings as errors), you can:

• Either relax that CI rule for peer-dependency warnings, or
• Replace ngx-datatable usage in your own code with another grid solution and remove it from your direct dependencies. But ABP’s theme will still bring it transitively until ABP replaces it in a future version; there is no official statement yet that it has been fully removed.

5. Recommended migration/upgrade path for ABP + Angular 20

1. Upgrade your solution to ABP 10.0.x using:
   • abp update (CLI), or
   • ABP Studio’s “Upgrade ABP Packages” action.
2. Let the tool update:
   • All NuGet packages to 10.0.x.
   • All NPM ABP Angular packages to 10.0.x, including Angular CLI/config files.
3. Ensure package.json @angular/* and @abp/* versions match what a fresh ABP 10 Angular template would generate (this is the safest way to avoid hidden version drift).
4. Delete node_modules + lock file, reinstall.
5. Confirm:

npm ls @angular/core

shows a single 20.0.x install. 6. Re-run:

ng build --configuration production

in CI and locally.

This aligns your project with ABP’s official Angular 20 setup and eliminates the duplicate-core TS2451 errors.

2. Sources

• ABP 10.0 Migration Guide (includes .NET 10 and Angular 20 template changes):
  https://abp.io/docs/10.0/release-info/migration-guides/abp-10-0

• ABP 10.0 RC Announcement (details Angular 20 / new esbuild-based builder and SSR for Angular UI):
  https://abp.io/community/announcements/announcing-abp-10-0-release-candidate-86lrnyox

• Angular UI Migration v2.9 → v3 (older, but shows ABP’s pattern of tightly coupling a specific Angular major to an ABP major):
  https://abp.io/docs/latest/framework/ui/angular/migration-guide-v3

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.

1. Solution

The CORE_OPTIONS error is not caused by your tsconfig.json anymore (your paths look correct). In ABP Angular, this error is almost always due to version mismatches or an extra CoreModule.forRoot/import. Below is a concrete checklist that fixes the issue in 9.x projects.

A. Normalize all ABP / Volosoft / Angular versions

1. In your package.json, make sure all of these have the same minor version line:

• @abp/ng.* → ~9.2.4
• @volo/abp.ng.* → ~9.2.4
• @volosoft/abp.ng.theme.lepton-x → ~4.2.4 (this is correct for ABP 9.2.x)
• @volo/ngx-lepton-x.core → ~4.2.4
• @angular/* → all the same major/minor (one line, e.g. all ~18.x.x or all ~19.x.x – but all must be identical)

Make sure there is no different version of any of these packages pulled in indirectly; if you see any other version ranges (like ^9.1.x or ~9.0.x) for @abp, @volo or @volosoft in dependencies or devDependencies, change them to ~9.2.4 to match.

In a very similar support case, the exact same CORE_OPTIONS error disappeared as soon as all @abp/*, @volo/* and the theme package were normalized to the same minor version.

2. After editing package.json, fully clear and reinstall:

# in the Angular project folder
rm -rf node_modules .angular yarn.lock package-lock.json
yarn cache clean || npm cache clean --force

yarn        # or npm install
yarn start  # or npm start

B. Ensure CoreModule is imported only once with forRoot

Check all your Angular modules for @abp/ng.core imports.

1. In AppModule (root), it must be:

CoreModule.forRoot({
  environment,
  registerLocaleFn: registerLocale(),
}),

2. In all other modules (shared/feature libraries), you must not call forRoot. If you import CoreModule there, it should be without forRoot:

// ✅ allowed in feature/shared modules
import { CoreModule } from '@abp/ng.core';

@NgModule({
  imports: [
    CoreModule,      // WITHOUT .forRoot()
    // ...
  ],
})
export class SomeFeatureModule {}

If you have any other CoreModule.forRoot(...) in the project (including inside your own libraries), Angular will create a separate injector that does not get the CORE_OPTIONS from your main AppModule, and RestService (from @abp/ng.core) will fail with exactly the error you see.

So:

• Search the whole solution for CoreModule.forRoot and keep it only in AppModule.
• Replace any other occurrences with just CoreModule.

C. Double‑check you are not using local/custom ABP Angular package sources

The support context for this error also shows it happens when a project:

• Has local copies of ABP / Volosoft Angular packages, or
• Has tsconfig paths pointing to those local copies.

You already set:

"paths": {
  "@abp/*": ["node_modules/@abp/*"],
  "@volo/*": ["node_modules/@volo/*"],
  "@proxy": [ "src/app/proxy/index.ts" ],
  "@proxy/*": [ "src/app/proxy/*" ]
}

Now verify that:

• There are no other tsconfig*.json files (in libs/projects) that override @abp/* or @volo/* to some local folder.
• You are not checking in customized ABP/Volosoft Angular package source under your repo and referencing it via paths.

If you find any path like "@volo/abp.ng.identity": ["projects/identity/src/public-api.ts"] etc., remove those mappings (or rename your custom libs to a different prefix) so @abp/* and @volo/* always resolve to node_modules.

D. Fix the “Cannot find the en locale file” error

This is usually resolved automatically once CoreModule.forRoot + registerLocaleFn run from the correct @volo/abp.ng.language-management version, but verify:

1. Import and use registerLocale exactly like this (which you already do):

import { registerLocale } from '@volo/abp.ng.language-management/locale';

CoreModule.forRoot({
  environment,
  registerLocaleFn: registerLocale(),
}),

2. Ensure the localization assets are copied:

Your angular.json (or workspace config) app’s assets section should include ABP localization assets (in a 9.x Angular app this is done by the template). Make sure these lines (or their equivalent) exist for your main app:

"assets": [
  "src/favicon.ico",
  "src/assets",
  {
    "glob": "**/*",
    "input": "node_modules/@abp/ng.theme.shared/assets",
    "output": "/assets"
  }
]

There needs to be an en locale JSON under /assets (e.g. /assets/abp-localization/en.json or similar). If the assets from @abp/ng.theme.shared are not copied, you get the “Cannot find the en locale file” error.

Rebuild after any change to angular.json:

yarn start --configuration development  # or just yarn start (depending on your setup)

Once the versions are normalized, CoreModule.forRoot is only in AppModule, and localization assets are in place, both:

• NullInjectorError: No provider for InjectionToken CORE_OPTIONS!
• Cannot find the en locale file.

should be resolved on a clean build.

2. Sources

• ABP Angular Localization (adding cultures & locale files)
  https://abp.io/docs/latest/framework/ui/angular/localization

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.

1. Solution

The NullInjectorError: No provider for InjectionToken CORE_OPTIONS! and the “Cannot find the en locale file” error are both symptoms of the same root cause: Angular is not resolving the correct @abp/* / @volo/* packages (so the DI configuration from @abp/ng.core is never applied, and the locale files can’t be found).

This exact issue is known on ABP 9.x Angular (see Microservice template case) and is fixed by normalizing the TypeScript paths so they point to node_modules.

Do the following in your Angular app (the one that contains app.module.ts you shared):

1. Edit tsconfig.json of the Angular app (usually apps/angular/tsconfig.json in microservice templates, or root tsconfig.json in single app):

   Add/merge these paths under compilerOptions:

{
     "compilerOptions": {
       // ...existing options...
       "paths": {
         // keep your existing paths, then add/override these:
         "@abp/*": ["node_modules/@abp/*"],
         "@volo/*": ["node_modules/@volo/*"]
       }
     }
   }

• If you already have @abp/* or @volo/* entries, make sure they only point to node_modules/@abp/* and node_modules/@volo/*, not to any local libs.

2. Clean and reinstall dependencies

   From the Angular project folder:

rm -rf node_modules
   rm -f package-lock.json yarn.lock
   # then
   yarn        # or npm install

3. Rebuild and run

yarn start  # or npm start

4. Verify your root module setup

   Your AppModule’s core setup is already correct for ABP 9.2.x:

CoreModule.forRoot({
     environment,
     registerLocaleFn: registerLocale(),
   }),

Once @abp/ng.core is correctly resolved from node_modules, this will:

• Provide CORE_OPTIONS (fixing the NullInjectorError).
• Load the default en locale (fixing “Cannot find the en locale file”).

After applying the paths fix and reinstalling dependencies, both errors should disappear on a fresh build.

2. Sources

• ABP Angular localization & culture files:
  https://abp.io/docs/latest/framework/ui/angular/localization

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.

1. Solution

CheckTokenExpiration() and IntrospectAccessToken() are just two different ABP helpers that plug into the cookie authentication pipeline:

• IntrospectAccessToken() (obsolete)

  • Uses OpenIddict introspection endpoint and sends the cookie’s access token together with this app’s ClientId.
  • OpenIddict then enforces: the caller (client doing introspection) must be in the token’s audience/presenter.
  • In your scenario you have multiple apps, each with its own ClientId, but you are sharing one login (SSO).
    • The access token may be issued for audience ControlCenter (or some other client/resource).
    • When APP‑2 introspects it with its own ClientId, OpenIddict sees that this ClientId is not in aud/azp and rejects the request:
      • Log: The introspection request was rejected because the access token was issued to a different client or for another resource server.
  • This is why some introspection calls return active: false even when the token itself is valid.

• CheckTokenExpiration() (new, recommended)

  • Does not use introspection in this strict way; it mainly checks token expiration and optionally calls user info.
  • Therefore it doesn’t hit the audience/presenter restriction that is causing your current error.

Because you have many apps (Portal, APP‑1/2/3) with SSO and different OpenIddict clients, IntrospectAccessToken() will always be fragile unless all access tokens are issued with all your frontend ClientIds as audiences.

The workaround suggested in the support thread is:

1. Remove options.IntrospectAccessToken() from all apps.
2. Copy and adjust ABP’s implementation to your own project:
   • File: CookieAuthenticationOptionsExtensions.cs
   • Source:
     https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.AspNetCore/Microsoft/Extensions/DependencyInjection/CookieAuthenticationOptionsExtensions.cs
3. In the copied CheckTokenExpiration/validation logic, change the ClientId used for introspection:
   • Instead of using each app’s own OIDC ClientId, take the ClientId (or audience) from the access token being validated, or use a single technical client that is always present in aud.
   • This bypasses the “token issued to a different client/resource server” condition you saw in OpenIddict’s ValidateIntrospectionRequest handler.

If you do this:

• You keep the behavior you like from IntrospectAccessToken (user is redirected to login when token is invalid/expired).
• You avoid the audience mismatch when the same token is reused across multiple apps with different ClientIds.

Regarding your last comment:

Using CheckTokenExpiration lets users access internal URLs without logging in, but IntrospectAccessToken does not.

That difference comes from the exact validation logic inside the ABP extension. Once you copy the extension code and adapt the introspection part (ClientId/audience logic) you can:

• Keep the “force login when no valid token” behavior,
• While still supporting your multi‑client, shared cookie (ApplicationName, Redis Protection-Keys shared) architecture.

2. Sources

• ABP cookie helpers for token checking and introspection (source code):
  • CookieAuthenticationOptionsExtensions
    https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.AspNetCore/Microsoft/Extensions/DependencyInjection/CookieAuthenticationOptionsExtensions.cs

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.