Asp.Net Core 3.0 Azure AppService中脚手架登录注册重定向失败

A developer ran into a tricky issue with their ASP.NET Core 3.0 application using Entity Framework Identity for standalone authentication:

• Locally, login/registration worked flawlessly—new users were saved to the Azure SQL database without issues.
• After deploying to Azure App Service, manually navigating to pages like https://www.myapp.com/en/Identity/Account/Login worked fine, but clicking the login or register buttons triggered a 404 error. No user records were created when attempting registration, and the app redirected straight to the error page.

Steps the Developer Tried #

Here’s a breakdown of all troubleshooting actions taken before resolving the issue:

• Upgraded to a paid App Service plan and configured a custom domain via GoDaddy (using a CNAME record to remove the .azurewebsites.net suffix)
• Added asp-area and asp-page attributes to <button> elements in the CSHTML login/register pages
• Enabled Azure Authentication/Authorization for the App Service and added http://www.myapp.com as a redirect URL
• Whitelisted all App Service outbound IP addresses in the Azure SQL database firewall
• Debugged with Chrome DevTools, but found no actionable clues
• Later additional checks:
  • Verified no localhost references existed in code (except IIS-related settings)
  • Added server/virtual inbound IPs (retrieved via nslookup) to the SQL firewall whitelist
  • Tested across browsers: Firefox showed a blank page, Edge displayed the 404 error
  • Toggled the RequireConfirmedAccount setting in startup.cs between true and false
  • Confirmed all CSHTML files had their Build Action set to Content
  • Completed Azure custom domain verification via GoDaddy DNS records
  • Tried replacing <button> elements with <a> or <input> buttons
  • Commented out UseHsts configuration for production in startup.cs
  • Hardcoded returnUrl values and modified redirect logic
  • Ensured login/register page models had the [AllowAnonymous] attribute (no global authorization restrictions)
  • Adjusted Identity password rules, which resulted in an "Invalid Login Attempt" error but still didn’t fix registration/login
  • Reached out to Microsoft technical support

Final Outcome #

The issue was resolved, but due to the large number of changes made during troubleshooting, the exact root cause hasn’t been pinpointed yet. The developer plans to reproduce the issue to identify the specific fix.

Expert Analysis: Likely Root Causes to Investigate #

Since manual page loads worked but form submissions failed, these are the most probable culprits to explore when reproducing the issue:

1. Route Generation Mismatch: Even with asp-area/asp-page added, there may be a conflict with localization (noted in the /en/ URL segment) or custom domain settings. Use browser DevTools to inspect the form’s action attribute and confirm it generates the correct production URL.
2. HTTPS/Redirect Misconfiguration: If the custom domain uses HTTPS, ensure UseHttpsRedirection is properly set up in startup.cs, and that Azure’s Authentication/Authorization settings aren’t overriding Identity routes.
3. Scaffolded Identity Route Conflicts: Scaffolded Identity pages can have route mismatches if the app uses localization or custom area setups. Double-check the @page directives in the login/register CSHTML files to ensure they align with the expected route structure.
4. Deployment Gaps: Verify all scaffolded Identity files were properly deployed to App Service (use the Kudu console to check file presence). Missing files could trigger 404s during form submission.
5. Network/Firewall Misconfiguration: Even with IPs whitelisted, there might be a misalignment in SQL firewall or App Service network settings preventing the app from communicating with the database during form processing (the lack of new user records suggests the request either didn’t reach the app or failed before database access).

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