Activities of "maliming"

hi

There will be code sending a POST request. Please check it in the browser’s network panel.

Thanks.

hi

Can you share the JSON response of signalr-hubs/chat/negotiate?negotiateVersion=1 endpoint?

Thanks.

hi

Can you share an online website URL?

liming.ma@volosoft.com

Thanks

Hi,

Thanks for the screenshots — checked them, that DCOTPolicies.Attestations.ApiAccess policy is unrelated to the 2FA redirect.

To move forward, could you share two things:

1. Full debug logs of one failing 2FA login(reproduce the problem).
2. A Chrome HAR file capturing all requests/responses from clicking Login until the browser lands back on the login page

Please follow this guide to enable all debug levels and HAR file: https://abp.io/support/questions/8622/How-to-enable-Debug-logs-for-troubleshoot-problems

Since the support form won't let you attach txt/zip, please email both files to liming.ma@volosoft.com and just reply here saying you've sent them.

Thanks

hi

Can you try again?

Thanks.

Hi,

One quick clarification on the Authorization failed lines you pasted earlier — those are not coming from ABP's standard permission system.

ABP's permission checks go through PermissionRequirement (created by AbpAuthorizationPolicyProvider), and a failing ABP permission check would log as:

Authorization failed. These requirements were not met:
PermissionRequirement: DCOT.AttestationAlerts

What you're seeing is:

ClaimsAuthorizationRequirement:Claim.Type=DCOT.AttestationAlerts and Claim.Value is one of the following values: (true)

ClaimsAuthorizationRequirement is ASP.NET Core's built-in type produced by policy.RequireClaim(...). It doesn't come from ABP — it's produced by hand-written AddAuthorization code somewhere in your solution.

The DCOT.AttestationAlerts / DCOT.AttestationAlerts.Edit / DCOT.PageSnapshots names are almost certainly ABP permission names (ABP writes granted permissions into the principal as claims — claim type = permission name, value = "true" — via IAbpClaimsPrincipalContributor). But the fact that they're checked with ClaimsAuthorizationRequirement (all three in one policy) tells us there's a custom policy built like this somewhere in your code:

services.AddAuthorization(options =>
{
    options.AddPolicy("SomePolicyName", policy =>
        policy.RequireClaim("DCOT.AttestationAlerts", "true")
              .RequireClaim("DCOT.AttestationAlerts.Edit", "true")
              .RequireClaim("DCOT.PageSnapshots", "true"));

    // If the same policy is also assigned as the fallback, every endpoint without
    // an explicit [AllowAnonymous] will go through it — including /Account/SendSecurityCode
    options.FallbackPolicy = options.GetPolicy("SomePolicyName");
});

If that policy is set as FallbackPolicy / DefaultPolicy, or applied via Razor Pages conventions (AuthorizeFolder / AuthorizePage), it will kick in on /Account/SendSecurityCode too. A 2FA-mid-flow user only holds the TwoFactorUserIdScheme cookie, which does not carry those DCOT.* claims — so the page gets rejected and ASP.NET Core redirects the browser back to /Account/Login. That's a perfect match for your symptom (login → straight back to login, no 2FA screen), and it also explains why non-2FA accounts work (they get the full application cookie with all claims in a single POST, so they pass the fallback policy on subsequent requests).

Could you please search your solution for:

• Any services.AddAuthorization(options => ...) or Configure<AuthorizationOptions>(options => ...) blocks — especially anything setting FallbackPolicy or DefaultPolicy.
• Any RequireClaim("DCOT.AttestationAlerts"...), RequireClaim("DCOT.PageSnapshots"...) usages.
• Any Configure<RazorPagesOptions>(options => options.Conventions.AuthorizeFolder(...)) / AuthorizePage(...) that pulls in that policy.

Share the snippets you find and we'll pinpoint the fix. If it is a fallback policy, the fix is usually either to scope the policy to specific endpoints (e.g. your API controllers via [Authorize("SomePolicyName")]) instead of using FallbackPolicy, or to explicitly allow /Account/* through.

Alongside the config, the full debug log for one failing login attempt from POST /Account/Login until the browser ends up back on /Account/Login is still the other thing we really need — the snippet you sent before only covered the login page rendering (GETs for JS files), not the actual POST + redirect chain.

Thanks

hi

We will check and fix it

Thanks.

hi

I sent the code.

Thanks.

hi

Could you send an email to liming.ma@volosoft.com?

I'll share the source code with you. The next version of the CLI will let you download it.

Thanks.

hi

We will fix it today. I will let you know. Sorry about the delay.