ABP Upgrade 8 to 10, Gateway Account Admin path #10631

6 Answer(s)

• 

  0

  AI-Bot created 4 months ago

  Support Team ABP Agent

  • Yes — when migrating the Microservice template gateway from Ocelot to YARP, you should align your gateway routes with the current ABP template conventions, i.e. use:

    • "/api/account-admin/{**catch-all}" (YARP catch-all syntax)

  • Your Ocelot route:

    • "/api/account-admin/{everything}" is functionally the same intent (a catch-all), just using Ocelot’s placeholder style. In YARP the equivalent is {**catch-all}.

  • No AuthServer backend code change is required just because of this route change, as long as:

    1. The AuthServer still exposes its endpoints under the same prefix (i.e. /api/account-admin/...), and
    2. Your gateway forwards that path to the AuthServer cluster.

  • What you need to do is only gateway configuration (YARP) consistency:

    • Keep the upstream path as /api/account-admin/...
    • Route it to the same cluster you use for AuthServer (as in the ABP template: ClusterId: "AuthServer")

    Example YARP route (as template):

  "AccountAdmin": {
      "ClusterId": "AuthServer",
      "Match": {
        "Path": "/api/account-admin/{**catch-all}"
      }
    }
  

  • Practical note during upgrade:
    • If your existing clients (Angular/Blazor/etc.) already call /api/account-admin/..., then switching the gateway from Ocelot to YARP with the route above will be transparent.
    • If you had any custom upstream path mapping in Ocelot (different upstream vs downstream), then you’d replicate that in YARP with Match.Path + Transforms (but in what you shared, upstream == downstream, so no transform is needed).

  Sources:

  • https://abp.io/docs/latest/solution-templates/microservice/api-gateways
  • https://abp.io/docs/10.2/solution-templates/microservice/api-gateways

  ---

  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.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 4 months ago

  Support Team Fullstack Developer

  Hi,

  Yes, you should follow the new template and route /api/account-admin/{**catch-all} to the AuthServer cluster, not Identity. Starting from ABP 8.0, the account-admin endpoints (login/auth related settings such as two-factor, recaptcha, external providers, idle timeout, passkey) were moved from IdentityService to AuthServer as the official architecture, and the gateway templates were updated accordingly when we switched from Ocelot to YARP.

  So your gateway route should look like this (this is exactly what the latest microservice template ships):

  "AccountAdmin": {
    "ClusterId": "AuthServer",
    "Match": {
      "Path": "/api/account-admin/{**catch-all}"
    }
  }
  

  On the AuthServer backend side, please double-check two places:

  1. MyCompanyName.MyProjectName.AuthServer.csproj references both Account Admin packages (use the same version as the rest of your ABP packages):

  <PackageReference Include="Volo.Abp.Account.Pro.Admin.HttpApi" Version="10.x.x" />
  <PackageReference Include="Volo.Abp.Account.Pro.Admin.Application" Version="10.x.x" />
  

  2. MyProjectNameAuthServerModule.cs declares the dependency:

  [DependsOn(
      // ... existing modules
      typeof(AbpAccountPublicWebOpenIddictModule),
      typeof(AbpAccountPublicApplicationModule),
      typeof(AbpAccountPublicHttpApiModule),
      typeof(AbpAccountAdminApplicationModule),
      typeof(AbpAccountAdminHttpApiModule),
      // ...
  )]
  public class MyProjectNameAuthServerModule : AbpModule
  {
  }
  

  If you upgraded with the ABP CLI those usually get applied for you, but for an 8 → 10 upgrade where the AuthServer project may have started life on an older template, it's worth verifying. Once those two pieces are in place, no other backend code change is required — the controllers (AccountSettingsController, route prefix api/account-admin/settings) come from Volo.Abp.Account.Pro.Admin.HttpApi and will be exposed by AuthServer automatically.

  After applying the change, you can confirm by hitting AuthServer's swagger directly and looking for the /api/account-admin/... endpoints there.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  DominaTang created 4 months ago

  I noticed both Auth Server swagger and Identity Service Swagger has /account-admin/ Controller.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 4 months ago

  Support Team Fullstack Developer

  Hi,

  Yes, that's expected — both services do register the AccountSettings controller because both IdentityService.HttpApi and AuthServer declare a dependency on AbpAccountAdminHttpApiModule. This is leftover from the older Ocelot template, where the gateway used to route /api/account-admin/... to IdentityService (port 44388). Starting from ABP 8.0 the gateway route was moved to AuthServer, but the dependency on the IdentityService side was kept in the template, so both services still surface the same endpoints in their swagger.

  Functionally it doesn't cause any issue:

  • The gateway only routes /api/account-admin/{**catch-all} to the AuthServer cluster, so the controller copy living inside IdentityService is never reached through the gateway.
  • You can simply ignore the duplicate appearing in IdentityService swagger — no code change needed on your side.

  If you really want to clean it up so IdentityService no longer exposes those endpoints, you can remove the Account Admin references from the IdentityService projects (IdentityService.HttpApi.csproj / IdentityService.Application.csproj and the matching [DependsOn(...)] entries in their module files). But this is purely cosmetic — keeping them as-is matches the current ABP template and is perfectly fine.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  DominaTang created 4 months ago

  thanks.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 4 months ago

  Support Team Fullstack Developer

  : )

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel