Blank page on /TwoFactor/Verify after successful 2FA (double submit → bare HTTP 400)

[GuidoSchaefer]

Blank page on /TwoFactor/Verify after successful 2FA (double submit → bare HTTP 400)

Summary

After entering a valid TOTP code, users sometimes end up on a completely blank page at /TwoFactor/Verify. Manually removing the path from the URL bar shows they are already logged in and the dashboard works. Cause: the verify form can be submitted twice, and the second POST fails antiforgery validation, which ASP.NET Core answers with an empty 400 Bad Request.

Environment

• Mail Archiver 2608.1 (Docker), behind Nginx Proxy Manager (reverse proxy, HTTPS)
• Safari 27 on macOS, but not browser-specific
• Local user with TOTP 2FA enabled

Steps to reproduce

1. Log in with username/password, land on /TwoFactor/Verify.
2. Type the 6-digit code and press Enter.
3. While the page is still visible (the redirect target / takes 2–3 s to render on a larger archive because the dashboard computes statistics), press Enter again or click Verify a second time.

What happens (reverse-proxy access log, timestamps to the second)

10:25:13  POST /TwoFactor/Verify  → 302 /            (code valid, user signed in)
10:25:15  GET  /                  → 499              (browser aborted the dashboard load)
10:25:15  POST /TwoFactor/Verify  → 400, body length 0

The second POST arrives after HttpContext.Session.Clear() and after the new auth cookie has been issued, so the antiforgery token from the form no longer matches. [ValidateAntiForgeryToken] short-circuits with a bare 400. Because Program.cs configures UseExceptionHandler("/Home/Error") but no UseStatusCodePages*, the browser renders an empty page while the address bar still shows /TwoFactor/Verify.

Expected

Either the second submit is prevented, or a failed antiforgery check on the 2FA page sends the user to / (already logged in → dashboard; not logged in → login page).

Suggested fixes (any one is enough, both together is best)

1. Prevent the double submit in Views/TwoFactor/Verify.cshtml (same idea for Views/Auth/Login.cshtml):

   <form asp-action="Verify" method="post" onsubmit="this.querySelector('button[type=submit]').disabled = true;">

   plus inputmode="numeric" autocomplete="one-time-code" maxlength="16" on the token input.

2. Turn a bare 400 into a redirect for the auth pages, e.g. in Program.cs:

   app.UseStatusCodePages(async ctx =>
   {
       var r = ctx.HttpContext.Response;
       var p = ctx.HttpContext.Request.Path;
       if (r.StatusCode == 400 && (p.StartsWithSegments("/TwoFactor") || p.StartsWithSegments("/Auth")))
           r.Redirect("/");
   });

   Alternatively an IAntiforgery-aware filter on TwoFactorController.Verify that redirects to Home/Index instead of returning 400.

Workaround we use meanwhile (Nginx Proxy Manager, "Advanced" of the host)

location = /TwoFactor/Verify {
    proxy_intercept_errors on;
    error_page 400 = @ma_home;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;
    include /etc/nginx/conf.d/include/proxy.conf;
}
location @ma_home { return 302 /; }

Related

This is probably the same root cause as the unanswered discussion #443 ("HTTP ERROR 400"), where a stale antiforgery cookie on a repeated login also produces a bare 400 page. That report was attributed to the reverse proxy, but the flow above shows the proxy forwards everything correctly and the 400 originates in the app.

Side note

Safari requests /apple-touch-icon.png and /apple-touch-icon-precomposed.png on every page load. Both are protected routes and answer with 302 /Auth/Login?returnUrl=..., which Safari retries, producing dozens of redirects per second in the access log. Serving those two paths anonymously (or a 204) would avoid that.