I followed the steps here to enforce SSL on my ASP.NET web API, but it always ends up in an infinite loop. What could I be doing wrong? The environment is Windows Server 2016 running in an AWS EC2 VM.
In my case, reverse proxy was on a separate server, so, my asp.net core app was not accepting this proxy because the proxy is no on ForwardedHeadersOptions.KnownProxies
and the network is not in ForwardedHeadersOptions.KnownNetworks
I apply this solution and the inifite loop dissapear:
services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders =
ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:100.64.0.0"), 106));
});
You can also use options.KnownProxies
and add the ip address of your reverse proxy, In my case I did not add because the reverse proxy is dynamic.
Pay attention to ::ffff:
you need to put this prefix, this is IPv4MappedToIPv6 address more information on https://github.com/aspnet/Docs/issues/2384#issuecomment-387875157
Thanks
Reverse proxies often terminate ssl so the back end app doesn't know. They should include the original scheme in a header. Use UseForwardedHeaders
for processing these. Have a look at this issue on GitHub.
I had the same redirect issue while integrating a .NET Core app with a Saml2 Idp from behind a loadbalancer/reverse proxy. (https => http)
For me it did the trick to set the Scheme of the request to https (or in my example with the provided proto header of the proxy)
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.All
});
app.Use((context, next) =>
{
if (context.Request.Headers.TryGetValue("X-Forwarded-Proto", out StringValues proto))
{
context.Request.Scheme = proto;
}
return next();
});
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With