为什么在我的网站上进行重定向会将我带到azure.websites.net而不是我的域？

Question

I have configured my web app to time out on idle by setting the following in the Startup.auth.cs file:

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
     ExpireTimeSpan = TimeSpan.FromHours(1),
     AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
     LoginPath = new PathString("/Account/Login"),
     SlidingExpiration = true,
     ....
}

My web app is behind a Virtual Network--->Application Gateway. The AG forwards the requests to the web app. I have also got rules that prevent direct access (ie myapp.azurewebsites.com) to the web app.

Now when the session times out, I get redirected to:

https://myapp.azurewebsites.net/Account/Login?ReturnUrl=%2Fcustomerarea

which is a blue screen with error 403(correct error), instead of my own domain like:

https://example.com/Account/Login?ReturnUrl=%2Fcustomerarea

Anyone knows why I would get this behavior? thanks.

Edit : more info...it looks like any redirect causes the above problem. So if I enter a URL https://example.com/customerarea which requires the user to login, then the redirected URL to the login page, has the azurewebsites.net in its address.

Answer 1

Any redirects without explicit host portions in the ASP.NET ecosystem will go to the host portion provided by the current HttpContext.Request .

Your application gateway will make the final request to your application (like a proxy) and addresses it as your .azurewebsites.net domain → meaning your ASP.NET app doesn't know about the original request to the gateway.

What you will need to do is to set the incoming request hostname to the original hostname from the request that went to your Application Gateway.

This documentation page (It's ASP.NET Core, but the same principle holds true for asp.net-mvc-5) should allow you to get an insight on how to overwrite your incoming HttpContext.Request hostname to the original. There are of course multiple ways.

1. Forwarded Headers (Which would then need to be set by your Application Gateway)
2. Config entry (Having a config entry with a "hardcoded" hostname)

Both approaches will just require extra middleware to override the current request according to the information gathered by either of these approaches.

Answer 2

So the above answer is correct. I am adding more information on how that fixes the problem in an MVC 5 web app. According to Microsoft's Application Gateway FAQ :

Application Gateway also inserts X-Original-Host header that contains the original Host header with which the request arrived. This header is useful in scenarios like Azure Website integration, where the incoming host header is modified before traffic is routed to the backend.

So to fix, I added the following code at the top of my Configuration (IAppBuilder app) method in the start.cs file:

app.Use(async (context, next) =>
{
  if (context.Request.Headers.GetValues("X-Original-Host") != null)
  {
    var originalHost = context.Request.Headers.GetValues("X-Original-Host").FirstOrDefault();
    context.Request.Headers.Set("Host", originalHost);
  }
  await next.Invoke();
});