<link rel="stylesheet" href="//fonts.googleapis.com/css?family=Open+Sans%3A300%2C400%2C600%2C700">Dealing with Application Base URLs and Razor link generation while hosting ASP.NET web apps behind Reverse Proxies July 2019

Dealing with Application Base URLs and Razor link generation while hosting ASP.NET web apps behind Reverse Proxies

  • July 11, 2019

Updating my site to run on AzureI’m quietly moving my Website from a physical machine to a number of Cloud Services hosted in Azure. This is an attempt to not just modernize the system – no reason to change things just to change them – but to take advantage of a number of benefits that a straight web host sometimes doesn’t have. I want to have multiple microsites (the main page, the podcast, the blog, etc) with regular backups, CI/CD pipeline (check in code, go straight to staging), production swaps, a global CDN for content, etc.

I’m also moving from an ASP.NET 4 (was ASP.NET 2 until recently) site to ASP.NET Core 2.x LTS and changing my URL structure. I am aiming to save money but I’m not doing this as a “spend basically nothing” project. Yes, I could convert my site to a static HTML generated blog using any number of great static site generators, or even a Headless CMS. Yes I could host it in Azure Storage fronted by a CMS, or even as a series of Azure Functions. But I have 17 years of content in DasBlog, I like DasBlog, and it’s being actively updated to .NET Core and it’s a fun app. I also have custom Razor sites in the form of my podcast site and they work great with a great workflow. I want to find a balance of cost effectiveness, features, ease of use, and reliability.  What I have now is a sinking feeling like my site is gonna die tomorrow and I’m not ready to deal with it. So, there you go.

Currently my sites live on a real machine with real folders and it’s fronted by IIS on a Windows Server. There’s an app (an IIS Application, to be clear) leaving at so that means hanselman.com/ hits / which is likely c:inetpubwwwroot full stop.

For historical reasons, when you hit hanselman.com/blog/ you’re hitting the /blog IIS Application which could be at d:whatever but may be at c:inetpubwwwrootblog or even at c:blog. Who knows. The Application and ASP.NET within it knows that the site is at hanselman.com/blog.

That’s important, since I may write a URL like ~/about when writing code. If I’m in the hanselman.com/blog app, then ~/about means hanselman.com/blog/about. If I write /about, that means hanselman.com/about. So the ~ is a shorthand for “starting at this App’s base URL.” This is great and useful and makes Link generation super easy, but it only works if your app knows what it’s server-side base URL is.

To be clear, we are talking about the reality of the generated URL that’s sent to and from the browser, not about any physical reality on the disk or server or app.

I’ve moved my world to three Azure App Services called hanselminutes, hanselman, and hanselmanblog. They have names like http://hanselman.azurewebsites.net for example.

ASIDE: You’ll note that hitting hanselman.azurewebsites.com will hit an app that looks stopped. I don’t want that site to serve traffic from there, I want it to be served from http://hanselman.com, right? Specifically only from Azure Front Door which I’ll talk about in another post soon. So I’ll use the Access Restrictions and Software Based Networking in Azure to deny all traffic to that site, except traffic from Azure – in this case, from the Azure Front Door Reverse Proxy I’ll be using.

That looks like this in this Access Restrictions part of the Azure Portal.

Only allowing traffic from Azure

Since the hanselman.com app will point to hanselman.azurewebsites.net (or one of its staging slots) there’s no issue with URL generation. If I say / I mean /, the root of the site. If I generate a URL like “~/about” I’ll get hanselman.com/about, right?

But with http://hanselmanblog.azurewebsites.net it’s different.

I want hanselman.com/blog/ to point to hanselmanblog.azurewebsites.net.

That means that the Azure Front Door will be receiving traffic, then forward it on to the Azure Web App. That means:

  • hanselman.com/blog/foo -> hanselmanblog.azurewebsites.net/foo
  • hanselman.com/blog/bar -> hanselmanblog.azurewebsites.net/foo
  • hanselman.com/blog/foo/bar/baz -> hanselmanblog.azurewebsites.net/foo/bar/baz

There’s a few things to consider when dealing with reverse proxies like this.

Is part of the /path being removed or is a path being added?

In the case of DasBlog, we have a configuration setting so that the app knows where it LOOKS like it is, from the Browser URL’s perspective.

My blog is at /blog so I add that in some middleware in my Startup.cs. Certainly YOU don’t need to have this in config – do whatever works for you as long as context.Request.PathBase is set as the app should see it. I set this very early in my pipeline.

That if statement is there because most folks don’t install their blog at /blog, so it doesn’t add the middleware.

//if you've configured it at /blog or /whatever, set that pathbase so ~ will generate correctly

Uri rootUri = new Uri(dasBlogSettings.SiteConfiguration.Root);
string path = rootUri.AbsolutePath;

//Deal with path base and proxies that change the request path
if (path != "/")

app.Use((context, next) =>

context.Request.PathBase = new PathString(path);
return next.Invoke();
);

Sometimes you want the OPPOSITE of this. That would mean that I wanted, perhaps hanselman.com to point to hanselman.azurewebsites.net/blog/. In that case I’d do this in my Startup.cs’s ConfigureServices:

app.UsePathBase("/blog");

Be aware that If you’re hosting ASP.NET Core apps behind Nginx or Apache or really anything, you’ll also want ASP.NET Core to respect  X-Forwarded-For and other X-Forwarded standard headers. You’ll also likely want the app to refuse to speak to anyone who isn’t a certain list of proxies or configured URLs.

I configure these in Startup.cs’s ConfigureServices from a semicolon delimited list in my config, but you can do this in a number of ways.

services.Configure<ForwardedHeadersOptions>(options =>


options.ForwardedHeaders = ForwardedHeaders.All;
options.AllowedHosts = Configuration.GetValue<string>("AllowedHosts")?.Split(';').ToList<string>();
);

Since Azure Front Door adds these headers as it forwards traffic, from my app’s point of view it “just works” once I’ve added that above and then this in Configure()

app.UseForwardedHeaders();

There seems to be some confusion on hosting behind a reverse proxy in a few GitHub Issues. I’d like to see my scenario ( /foo -> / ) be a single line of code, as we see that the other scenario ( / -> /foo ) is a single line.

Have you had any issues with URL generation when hosting your Apps behind a reverse proxy?


Sponsor: Develop Xamarin applications without difficulty with the latest JetBrains Rider: Xcode integration, JetBrains Xamarin SDK, and manage the required SDKs for Android development, all right from the IDE. Get it today


© 2019 Scott Hanselman. All rights reserved.

jaksuka

E-mail : [email protected]

      Submit A Comment

      Must be fill required * marked fields.

      :*
      :*