如何解決asp.net core中負(fù)載均衡場(chǎng)景下http重定向https的問題

本篇文章給大家分享的是有關(guān)如何解決asp.net core中負(fù)載均衡場(chǎng)景下http重定向https的問題，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

上周欣喜地發(fā)現(xiàn)，微軟官方終于針對(duì) asp.net core 在使用負(fù)載均衡的情況下從 http 強(qiáng)制重定向至 https 的問題提供了解決方法。

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedProto
});var options = new RewriteOptions()
    .AddRedirectToHttpsPermanent();
app.UseRewriter(options);

但實(shí)際使用之后，欣喜變成了失望 —— 微軟對(duì)這個(gè)問題的認(rèn)識(shí)角度和我們不一樣，造成這個(gè)方法對(duì)我們不適用，不得不繼續(xù)使用我們的土方法。

為什么會(huì)這樣？請(qǐng)看下面的分解。 

AddRedirectToHttpsPermanent 早就在 BasicMiddleware 的 RedirectToHttpsRule 中實(shí)現(xiàn)了，它的邏輯很簡(jiǎn)單 —— 判斷當(dāng)前請(qǐng)求是否是https，如果不是就進(jìn)行重定向。

if (!context.HttpContext.Request.IsHttps)
{    //...}

這個(gè)直接了當(dāng)?shù)呐袛嘣谑褂秘?fù)載均衡的場(chǎng)景下不僅不會(huì)發(fā)揮應(yīng)有的作用，而且會(huì)產(chǎn)生致命的副作用 —— 讓請(qǐng)求進(jìn)入重定向死循環(huán)（ERR_TOO_MANY_REDIRECTS）。因?yàn)椴还芸蛻舳说恼?qǐng)求是 http 還是 https ，負(fù)載均衡與后端服務(wù)器之間始終是 http（當(dāng)然你可以用https，但那是吃飽了撐著還浪費(fèi)糧食）。如果負(fù)載均衡不額外提供這個(gè)信息，在后端服務(wù)器的眼里始終只有 http 沒有 https ，http 重定向 https 根本無(wú)法實(shí)現(xiàn)。

從負(fù)載均衡的角度，為了解決這個(gè)問題，通常會(huì)通過一個(gè)另外的專用的請(qǐng)求頭抓發(fā)這個(gè)信息，它的名字叫"X-Forwarded-Proto"。

從 asp.net core 的角度，要解決這個(gè)問題，需要彌補(bǔ) Request.IsHttps 與 X-Forwarded-Proto 之間的鴻溝。于是微軟實(shí)現(xiàn)了上面的 app.UseForwardedHeaders() ，實(shí)際是由 ForwardedHeadersMiddleware 完成這個(gè)任務(wù) —— 根據(jù) X-Forwarded-Proto 設(shè)置 Scheme（Request.IsHttps 就是基于 Scheme 進(jìn)行判斷的）。

if (checkProto && i < forwardedProto.Length)
{    set.Scheme = forwardedProto[forwardedProto.Length - i - 1];
}

到此為止，微軟完美地解決了這個(gè)問題，RedirectToHttpsRule 不用修改1行代碼。

但是在實(shí)際使用時(shí)，我們發(fā)現(xiàn)一個(gè)大問題，大到我們必須棄用這個(gè)看似完美的解決方法。

微軟解決 http to https 問題的思路是這樣：只要請(qǐng)求不是 https 的，就強(qiáng)制跳轉(zhuǎn)到 https（這個(gè)沒問題），其他一概不管，不管這個(gè)請(qǐng)求是不是來自負(fù)載均衡轉(zhuǎn)發(fā)的（這個(gè)不夠貼心）。

而我們要解決的問題是：只有在負(fù)載均衡轉(zhuǎn)發(fā)的原始請(qǐng)求是 http 的情況下，才強(qiáng)制跳轉(zhuǎn)至 https 。比如在服務(wù)器本機(jī)訪問，比如來自其他docker容器的訪問，如果這也跳轉(zhuǎn)，那每臺(tái)服務(wù)器（或者docker容器）都要部署https證書，多麻煩。

一個(gè)是只要不是 https ，就跳轉(zhuǎn)；一個(gè)是只有是轉(zhuǎn)發(fā)的 http ，才跳轉(zhuǎn)。 就是因?yàn)檫@個(gè)對(duì)問題理解的差異，我們不得不放棄采用微軟的官方解決方法，繼續(xù)使用我們不太優(yōu)雅的土方法。

RedirectToProxiedHttpsRule

public class RedirectToProxiedHttpsRule : RedirectToHttpsRule
{ 
   public RedirectToProxiedHttpsRule()
    {       
           base.StatusCode = StatusCodes.Status301MovedPermanently;     
              base.SSLPort = null;
    }   
    
     public override void ApplyRule(RewriteContext context)
    {      
       var key = "X-Forwarded-Proto";      
       var request = context.HttpContext.Request;   
       if (request.Headers.ContainsKey(key))
        {         
          if (request.Headers[key].FirstOrDefault() == "http")
            {               
           base.ApplyRule(context);
            }
        }
    }
}

RewriteOptionsExtensions

public static class RewriteOptionsExtensions
{   
 public static RewriteOptions AddRedirectForwardedHttpToHttps(this RewriteOptions options)
    {
        options.Rules.Add(new RedirectToProxiedHttpsRule());     
   return options;
    }
}

在 Startup 中使用

var options = new RewriteOptions()
    .AddRedirectForwardedHttpToHttps();
app.UseRewriter(options);

以上就是如何解決asp.net core中負(fù)載均衡場(chǎng)景下http重定向https的問題，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。