Activities of "maliming"

hi

We will check your license.

Thanks.

hi

You can override the CreateAsync method and remove the DataSeeder.SeedAsync code.

https://abp.io/docs/latest/framework/architecture/modularity/extending/customizing-application-modules-overriding-services

Thanks.

ok, 👍

hi

You can try changing an email in https://account.abp.io/Account/Manage, and then send an email. How about that?

hi

You can send an email to info@abp.io

Thanks.

hi

Volo.Abp.TenantManagement is an open-source module. You have a commercial license; you should use Volo.Saas.Host.Application

But I will check the open source side as well.

Thanks.

Hi, is the code you shared from the ABP module, or is it your own custom code?

Thanks.

Hey, thanks for the detailed logs — super helpful.

So we dug into the diagnostic output and your source code, and here's where we landed:

The Bearer token is definitely reaching the API tier (825 chars every time), but the API is treating every request as anonymous. We checked your HttpApiHostModule and noticed you've disabled dynamic claims:

options.IsDynamicClaimsEnabled = false;
options.DynamicContributors.Clear();

So IdentitySessionDynamicClaimsPrincipalContributor isn't even in the picture. The problem is happening earlier — the JwtBearer handler itself is failing to validate the token. When that happens, HttpContext.User stays anonymous, and you get empty GrantedPolicies on every cache-miss request.

Your API uses AddAbpJwtBearer with Authority from config and Audience = "CabMD". Your AuthServer sets the issuer via serverBuilder.SetIssuer(configuration["AuthServer:Authority"]). ABP calls DisableAccessTokenEncryption() unconditionally — we checked your entire codebase, nothing re-enables it — so the token should be a plain JWT. But 100% of validations are failing, and we can't tell why from the source code alone because both sides read AuthServer:Authority from their own config, and the production values come from Azure env vars (not in appsettings).

We've pushed a bunch of updates to the PR:

New diagnostic hooks — we added a DiagnosticJwtBearerPostConfigure that taps directly into the JwtBearer handler events. After deploying, look for these in your API logs:

• ABP_DIAG: JwtBearer OnAuthenticationFailed — this is the big one. It'll show the exact exception (signature key not found? issuer mismatch? audience mismatch?), plus the JWT's decoded issuer, audience, expiry, the configured Authority, and the raw token itself.
• ABP_DIAG: JwtBearer OnTokenValidated SUCCESS — if you see this, validation is actually working and we need to look elsewhere.
• ABP_DIAG: JwtBearer OnMessageReceived — confirms the handler is receiving the token and whether it's actually a JWT.

IdentityModel verbose logging — we enabled ShowPII = true and EventLevel.Verbose in Program.cs. This writes the full JWT validation pipeline to Logs/identitymodel.txt in the API host's working directory — every step of key lookup, signature check, issuer/audience validation, with nothing masked.

Log levels bumped to Debug — across HttpApi.Host, Web, and AuthServer, both dev and production configs. Serilog MinimumLevel and Microsoft.AspNetCore.Authentication are both set to Debug now.

Could you pull the latest, deploy, and then share the following after reproducing the issue?

• Logs/identitymodel.txt from the API host
• Complete log files from all three projects — HttpApi.Host, Web, and AuthServer

The identitymodel.txt alone should tell us exactly what's going wrong with the JWT validation. The full logs from all projects might also reveal something we haven't thought of yet.

hi

Can you share the logs.txt files for all of your apps?

We need check the backend logs.

Debug Logs: https://abp.io/support/questions/8622/How-to-enable-Debug-logs-for-troubleshoot-problems

And you can refer to this article: https://abp.io/community/articles/Common%20Errors%20in%20JWT%20Bearer%20Authentication-4u3wrbs5#gsc.tab=0

Thanks.

Thank you for reporting this.

Blazorise 2.x is not supported in ABP 10.1.x. The Pro Blazor packages in 10.1.x were compiled against Blazorise 1.8.x, so upgrading Blazorise independently to 2.0.x will cause the runtime type load exceptions you are seeing (TextEdit was renamed to TextInput in Blazorise 2.0, among other breaking changes).

Blazorise 2.0 support is included in ABP 10.2, which is currently at RC stage. Please upgrade to ABP 10.2 once it is officially released to use Blazorise 2.0.

In the meantime, please downgrade Blazorise back to 1.8.x when using ABP 10.1.x.

Thanks.