Alright, let's tackle this 400 Bad Request issue you're seeing with POST requests in your Docker-deployed ASP.NET Core 2.1.4 app. Since you suspect it's linked to Antiforgery or Data Protection, let's break down the most likely culprits and actionable fixes based on your setup:

1. Data Protection Persistence & Container Isolation #

Since you're using a custom IXmlRepository with EF Core + PostgreSQL to store keys, first confirm these critical points:

• Verify database connectivity: Ensure your Docker container can reach the PostgreSQL instance. If you're using Docker Compose, double-check that your app service uses the correct database service name (not localhost) in the connection string. Permissions are another common pitfall—make sure the database user has read/write access to the keys table.
• Set a consistent application name: In your AddDataProtection() configuration, explicitly call SetApplicationName("YourUniqueAppName"). Without this, each Docker container instance might generate its own isolated key set, breaking token validation across instances.
• Validate key storage: Directly query your PostgreSQL table to confirm keys are being saved. If no keys exist, your custom IXmlRepository implementation has a bug—check that SaveAsync is properly persisting data and GetAllElementsAsync returns the stored keys correctly.

2. Antiforgery Configuration Mismatches #

Antiforgery relies heavily on Data Protection, so misconfigurations here will cause POST failures:

• Check secure cookie settings: In production, if you're using HTTPS (or a reverse proxy terminating HTTPS), ensure Antiforgery's cookie secure policy aligns. Use this configuration:

  services.AddAntiforgery(options =>
  {
      options.Cookie.SecurePolicy = CookieSecurePolicy.SameAsRequest;
      // Or CookieSecurePolicy.Always if you enforce HTTPS everywhere
  });
  

  If your Docker setup doesn't use HTTPS internally (common with reverse proxies), SameAsRequest prevents the cookie from being marked as secure when it shouldn't be.
• Confirm token delivery: For AJAX POST requests, make sure your frontend sends the Antiforgery token in either the request header (usually RequestVerificationToken) or as a form field. Mismatched token locations will trigger validation failures.
• Avoid custom token name mismatches: If you've customized the Antiforgery cookie or header name, ensure the frontend uses the exact same name when sending the token.

3. Docker & Reverse Proxy Specific Issues #

Docker deployments often introduce environment quirks that affect token validation:

• Forwarded headers configuration: If you're using a reverse proxy (Nginx, Traefik, etc.), ASP.NET Core needs to know about the original request details. Add this to your Configure method before other middleware:

  app.UseForwardedHeaders(new ForwardedHeadersOptions
  {
      ForwardedHeaders = ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedFor
  });
  

  Without this, the app might think requests are HTTP even when they're HTTPS, causing secure cookies to be rejected.
• Clock alignment: Ensure your Docker containers and PostgreSQL server have synchronized system clocks. A significant time difference can lead to Antiforgery tokens being incorrectly marked as expired.
• Container permissions: Confirm the user running your ASP.NET Core app in the container has sufficient permissions. While less likely with PostgreSQL-backed keys, permission issues can prevent the app from accessing necessary resources for key processing.

4. Debugging to Pinpoint the Exact Issue #

To narrow down the problem quickly:

• Enable detailed logging: Update your production appsettings.json to log debug-level messages for Data Protection and Antiforgery:

  {
    "Logging": {
      "LogLevel": {
        "Microsoft.AspNetCore.DataProtection": "Debug",
        "Microsoft.AspNetCore.Antiforgery": "Debug"
      }
    }
  }
  

  Look for logs indicating failed key loading or token validation—these will give you precise error details.
• Temporarily disable Antiforgery: Add [IgnoreAntiforgeryToken] to a test POST controller action. If the request succeeds, you've confirmed the issue is Antiforgery-related. Re-enable it immediately after testing.
• Inspect response details: In your browser's dev tools, check the POST request's response body. Often, 400 errors will include a message like "The antiforgery cookie token is missing" or "The token could not be decrypted"—this points directly to the root cause.

Based on your setup, the most likely fixes are ensuring consistent Data Protection key access across containers, configuring forwarded headers correctly for reverse proxies, and aligning Antiforgery cookie settings with your production HTTPS setup.

内容的提问来源于stack exchange，提问作者Corstiaan