Question

我按照here步骤在我的ASP.NET Web API上强制执行SSL，但它总是以无限循环结束。我能做错什么？环境是在AWS EC2 VM中运行的Windows Server 2016。

Answer 1

在我的情况下，反向代理位于单独的服务器上，因此我的asp.net核心应用未接受此代理，因为该代理不在ForwardedHeadersOptions.KnownProxies上，并且网络不在ForwardedHeadersOptions.KnownNetworks上我应用了此解决方案，并且消失了inifite循环：

services.Configure<ForwardedHeadersOptions>(options =>
        {
            options.ForwardedHeaders =
                ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
            options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:100.64.0.0"), 106));
        });

您还可以使用options.KnownProxies并添加反向代理的IP地址，但由于反向代理是动态的，因此我没有添加。

请注意::ffff:，您需要添加此前缀，这是关于https://github.com/aspnet/Docs/issues/2384#issuecomment-387875157的IPv4MappedToIPv6地址的更多信息

谢谢

Answer 2

反向代理通常会终止ssl，因此后端应用程序不知道。它们应该在标题中包含原始方案。使用UseForwardedHeaders进行处理。在GitHub上查看this issue。

Answer 3

从负载均衡器/反向代理后面集成.NET Core应用程序和Saml2 Idp时，我遇到了相同的重定向问题。（https => http）

对我来说，将请求的方案设置为https（或在我的示例中提供了代理的proto标头）上很巧妙

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();
});

Answer 4

我遇到了VictorV's solution解决的同一问题。但是，我无法控制正在运行该应用程序的网络。我稍微修改了他的答案，以（允许）允许来自任何网络的请求。

services.Configure<ForwardedHeadersOptions>(options =>
    {
        options.ForwardedHeaders =
            ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
        options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:0.0.0.0"), 0));
    });

虽然我确定这不太安全，但由于我无法控制网络，所以我真的没有其他选择。

在执行SSL时，ASP.NET核心中的无限重定向循环

4 个答案: