Earlier today I was running into weird issues detecting whether or not my .NET Core site was receiving HTTPS requests. After much gnashing of teeth, I believe I found a solution.
It turns out forcing HTTP requests to redirect to HTTPS and determining whether a request is HTTPS are a common/known issues that result from using your web server as a proxy to Kestrel. In my case, IIS is the front-end proxy server. Any attempts to detect whether a request was using HTTPS resulted in a negative result.
This is a problematic.
I read all sorts of github issues indicating that, especially in a load-balanced scenario, that additional headers should be forwarded to indicate whether a request is HTTPS. Without having access to the load balancer configuration though, this is a bit of a show-stopper. Other features such as URL rewriting with the AspNetCore rewrite module, obviously, do not work either since HTTPS is not detected properly. Basically, every solution results in infinite redirects.
As a result, I had to resort to adding a non-portable rewrite rule directly to the IIS servers I use in the load balanced configuration.
However, even with this in place and ensuring that all requests are HTTPS, .NET Core still generates URLs internally as HTTP. This breaks things like OAuth2 authorization grant flow using the built-in OAuth2 middleware. (ugh!)
One simple work around is to force the context of every request with a middleware interceptor:
// Force reporting https scheme
app.Use(async (context, next) =>
{
context.Request.Scheme = "https";
await next();
});
That middleware has to be one of the first handlers defined. It took me quite a bit of time to find that this directly affects the .NET Core OAuth2 middleware’s generation of any “redirect_uri” parameters.
I think I gained a few grey hairs in the process of finding a solution to this issue.