美聯社5日報導，通用汽車（General Motors）已開始在美國密西根州奧萊恩（Orion）鎮生產Chevrolet Bolt。這台續航力達238英里（383公里）的電動車建議零售價37,495美元起（註：最多可取得7,500美元的聯邦折抵稅額、扣除後入手價相當於29,995美元），今年底以前將於加州、奧勒岡州開賣，明年將擴及全美其他地區。根據凱利藍皮書（Kelley Blue Book）的統計，美國新車平均價格為34,000美元。特斯拉（Tesla Motors Inc.）200英里續航力、35,000美元（註：扣除聯邦折抵稅額前）Model 3電動車預計自2017年下半年開始交車。

IHS Markit汽車業分析師Stephanie Brinley指出，Bolt續航力遠高於美國平均來回通勤距離（40英里），但有時人們回家後可能忘了或沒有足夠時間進行充電，這是電動車主得多加費心的地方。美國目前使用中的電動車數量約23.5萬台，IHS預估Bolt開賣第一年銷售量逼近3萬台。美國去年電動車銷售量為10萬台，IHS預估年度銷售量將在2020年升至30萬台、2025年挑戰40萬台。

華爾街日報報導，通用汽車2015年10月宣布與LG電子結盟、後者將成為Chevrolet Bolt電動車的主要關鍵零件供應商。

英國金融時報8月報導，國際能源署（IEA）首席經濟學家Laszlo Varro指出，電動車目前對商品（原油）市場的影響力大約就像是10年前的太陽能一樣。他說，太陽能現在已是一個規模達數百億美元的市場、擁有龐大的影響力。Varro提到，電動車需達5千萬至1億台的規模、才能取代相當於100萬桶的石油日消費量。

IEA數據顯示，2009年全球40個國家合計僅有不到6千台的電動車、去年已升至120萬台。麥格理集團全球能源策略師Vikas Dwivedi指出，沙烏地阿拉伯對電動車的長期發展存有戒心，這可能就是它為何宣布將讓沙烏地阿拉伯國家石油公司（Saudi Aramco）初次公開發行（IPO）的原因之一。

CNNMoney去年底報導，石油輸出國組織（OPEC）發表的年度「世界石油展望（World Oil Outlook）」報告顯示，2040年高達94%的使用中車輛仍將是依靠石油燃料。OPEC報告顯示，除非出現重大技術性突破，否則在可預見的未來電動車將難以大幅取得市佔率。油國組織預估2040年僅有1%的車輛銷售量是來自純電動車款。

能源情報署（EIA）公布，截至2016年10月28日為止當週美國商用汽油庫存報2.238億桶、較去年同期高出3.9%。EIA公布的數據顯示，美國一般汽油每加侖零售均價10月31日報2.230美元，較一年前高出0.006美元。

（照片來源：。本文內容由 授權提供）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司“嚨底家”!

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※聚甘新

美商特斯拉（Tesla）於今年9月正式進軍台灣，在台引發電動車熱。台北萬豪酒店宣布與Tesla合作設置充電站，同時推出限時活動，鼓勵民眾響應環保行動。

繼在台灣科技大學校區內設置充電站後，Tesla正式宣布與台北萬豪酒店合作，於飯店內設置6組充電站，成為全台首家提供Tesla電動車充電服務的飯店。車主只要於飯店內消費，就可免費享有充電服務。

台北萬豪酒店主管表示，萬豪國際的核心理念是「擁抱改變」，不但要跟著時代進步，還要勇於創新，與Tesla的形象相輔相成。藉由與Tesla合作設置電動車充電站，希望能提供客戶更便捷的服務，並推動現代科技。

萬豪酒店同時也推出相關活動，凡是11月30日前佩戴紅色配件到萬豪酒店消費的顧客，就可享有9折優惠。

Tesla主管表示，Tesla進入台灣市場後，將提供銷售、服務、充電等全方位服務，未來將繼續加速布建「目的地充電站」的腳步，以為台灣的Tesla車主提供更綿密的充電網絡。

除了萬豪酒店之外，台北晶華酒店也與BMW合作設置了i公共充電站，可供i3、i8等車款使用。

（照片來源：）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※超省錢租車方案

※教你寫出一流的銷售文案?

※網頁設計最專業,超強功能平台可客製化

※聚甘新

德國媒體報導，汽車廠商BMW CEO Harald Krueger 在接受採訪時表示，電動車的時代即將到來，這一市場還有巨大的潛力，BMW 將在2017 年力爭把電動車的銷量提升到10 萬台，目前該公司2015 年電動車和混合動力車的銷量大約為6 萬台。

BMW CEO Harald Krueger 表示，該公司希望能夠在2017 年大幅提升電動車的銷量，至少提升六成，達到年銷量10 萬台。BMW 2016 年電動車和混合動力車的銷量合計大約為6 萬台，自2013 年發售電動車以來，BMW 電動車的雷軍銷量已經超過了10 萬台。

Harald Krueger 認為電動車的時代即將到來，這一市場還有很大的潛力，需求還沒有完全被發掘。

BMW 旗下唯一的純電動車車款i3 上市以來市場反響不如預期，2015 年i3 僅售出了2.5 萬台，為了提升這款產品的競爭力，BMW 將在2016 年的升級中把i3 系列電動車的續航里程提升50%。

在高階汽車市場中，BMW 的產品銷量已經落後於Benz，該公司希望在2025 年前將電動車和混合動力車的銷量提升到15%-25%。

（本文由《》授權提供。照片來源：）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※聚甘新

1.前言

回顧：認證方案之初步認識JWT

在現代Web應用程序中，即分為前端與後端兩大部分。當前前後端的趨勢日益劇增，前端設備（手機、平板、電腦、及其他設備）層出不窮。因此，為了方便滿足前端設備與後端進行通訊，就必須有一種統一的機制。所以導致API架構的流行。而RESTful API這個API設計思想理論也就成為目前互聯網應用程序比較歡迎的一套方式。

這種API架構思想的引入，因此，我們就需要考慮用一種標準的，通用的，無狀態的，與語言無關的身份認證方式來實現API接口的認證。

HTTP提供了一套標準的身份驗證框架：服務端可以用來針對客戶端的請求發送質詢(challenge)，客戶端根據質詢提供應答身份驗證憑證。

質詢與應答的工作流程如下：服務端向客戶端返回401（Unauthorized，未授權）狀態碼，並在WWW-Authenticate頭中添加如何進行驗證的信息，其中至少包含有一種質詢方式。然後客戶端可以在請求中添加Authorization頭進行驗證，其Value為身份驗證的憑證信息。

在本文中，將要介紹的是以Jwt Bearer方式進行認證。

2.Bearer認證

本文要介紹的Bearer驗證也屬於HTTP協議標準驗證，它隨着OAuth協議而開始流行，詳細定義見： RFC 6570。

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

A security token with the property that any party in possession of the token (a “bearer”) can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).

因此Bearer認證的核心是Token，Bearer驗證中的憑證稱為BEARER_TOKEN，或者是access_token，它的頒發和驗證完全由我們自己的應用程序來控制，而不依賴於系統和Web服務器，Bearer驗證的標準請求方式如下：

Authorization: Bearer [BEARER_TOKEN] 

那麼使用Bearer驗證有什麼好處呢？

• CORS: cookies + CORS 並不能跨不同的域名。而Bearer驗證在任何域名下都可以使用HTTP header頭部來傳輸用戶信息。
• 對移動端友好: 當你在一個原生平台(iOS, Android, WindowsPhone等)時，使用Cookie驗證並不是一個好主意，因為你得和Cookie容器打交道，而使用Bearer驗證則簡單的多。
• CSRF: 因為Bearer驗證不再依賴於cookies, 也就避免了跨站請求攻擊。
• 標準：在Cookie認證中，用戶未登錄時，返回一個302到登錄頁面，這在非瀏覽器情況下很難處理，而Bearer驗證則返回的是標準的401 challenge。

3.JWT

上面介紹的Bearer認證，其核心便是BEARER_TOKEN，那麼，如何確保Token的安全是重中之重。一種是通過HTTPS的方式，另一種是通過對Token進行加密編碼簽名，而最流行的Token編碼簽名方式便是：JSON WEB TOKEN。

Json web token (Jwt), 是為了在網絡應用環境間傳遞聲明而執行的一種基於JSON的開放標準（RFC 7519）。該token被設計為緊湊且安全的，特別適用於分佈式站點的單點登錄（SSO）場景。JWT的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，以便於從資源服務器獲取資源，也可以增加一些額外的其它業務邏輯所必須的聲明信息，該token也可直接被用於認證，也可被加密。

JWT是由.分割的如下三部分組成：

Header.Payload.Signature

還記得之前說個的一篇認證方案之初步認識JWT嗎？沒有的，可以看看，對JWT的特點和基本原理介紹，可以進一步的了解。

學習了之前的文章后，我們可以發現使用JWT的好處在於通用性、緊湊性和可拓展性。

• 通用性：因為json的通用性，所以JWT是可以進行跨語言支持的，像JAVA,JavaScript,NodeJS,PHP等很多語言都可以使用。
• 緊湊性：JWT的構成非常簡單，字節佔用很小，通過 GET、POST 等放在 HTTP 的 header 中，便於傳輸。
• 可擴展性：JWT是自我包涵的，因為有了payload部分，包含了必要的一些其他業務邏輯所必要的非敏感信息，自身存儲，不需要在服務端保存會話信息, 非常易於應用的擴展。

4.開始

1. 註冊認證服務

在這裏，我們用微軟給我們提供的JwtBearer認證方式，實現認證服務註冊 。

引入nuget包：Microsoft.AspNetCore.Authentication.JwtBearer

註冊服務，將服務添加到容器中，

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddControllers();

        var Issurer = "JWTBearer.Auth";  //發行人
        var Audience = "api.auth";       //受眾人
        var secretCredentials = "q2xiARx$4x3TKqBJ";   //密鑰

        //配置認證服務
        services.AddAuthentication(x =>
        {
            x.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
            x.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
        }).AddJwtBearer(o=>{
            o.TokenValidationParameters = new TokenValidationParameters
            {
                //是否驗證發行人
                ValidateIssuer = true,
                ValidIssuer = Issurer,//發行人
                //是否驗證受眾人
                ValidateAudience = true,
                ValidAudience = Audience,//受眾人
                //是否驗證密鑰
                ValidateIssuerSigningKey = true,
                IssuerSigningKey = new SymmetricSecurityKey(Encoding.ASCII.GetBytes(secretCredentials)),
                
                ValidateLifetime = true, //驗證生命周期
                RequireExpirationTime = true, //過期時間
            };
        });
    }

注意說明：

一. TokenValidationParameters的參數默認值：
1. ValidateAudience = true,  ----- 如果設置為false,則不驗證Audience受眾人
2. ValidateIssuer = true ,   ----- 如果設置為false,則不驗證Issuer發布人，但建議不建議這樣設置
3. ValidateIssuerSigningKey = false,
4. ValidateLifetime = true,  ----- 是否驗證Token有效期，使用當前時間與Token的Claims中的NotBefore和Expires對比
5. RequireExpirationTime = true, ----- 是否要求Token的Claims中必須包含Expires
6. ClockSkew = TimeSpan.FromSeconds(300), ----- 允許服務器時間偏移量300秒，即我們配置的過期時間加上這個允許偏移的時間值，才是真正過期的時間(過期時間 +偏移值)你也可以設置為0，ClockSkew = TimeSpan.Zero

調用方法，配置Http請求管道：

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }

        app.UseRouting();
        //1.先開啟認證
        app.UseAuthentication();
        //2.再開啟授權
        app.UseAuthorization();

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapControllers();
        });
    }

在JwtBearerOptions的配置中，通常IssuerSigningKey(簽名秘鑰), ValidIssuer(Token頒發機構), ValidAudience(頒發給誰) 三個參數是必須的，后兩者用於與TokenClaims中的Issuer和Audience進行對比，不一致則驗證失敗。

2.接口資源保護

創建一個需要授權保護的資源控制器，這裏我們用建立API生成項目自帶的控制器，WeatherForecastController.cs, 在控制器上使用Authorize即可

[ApiController]
[Route("[controller]")]
[Authorize]
public class WeatherForecastController : ControllerBase
{
    private static readonly string[] Summaries = new[]
    {
        "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
    };

    private readonly ILogger<WeatherForecastController> _logger;

    public WeatherForecastController(ILogger<WeatherForecastController> logger)
    {
        _logger = logger;
    }

    [HttpGet]
    public IEnumerable<WeatherForecast> Get()
    {
        var rng = new Random();
        return Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = DateTime.Now.AddDays(index),
            TemperatureC = rng.Next(-20, 55),
            Summary = Summaries[rng.Next(Summaries.Length)]
        })
        .ToArray();
    }
}

3. 生成Token

因為微軟為我們內置了JwtBearer驗證，但是沒有提供Token的發放，所以這裏我們要實現生成Token的方法

引入Nugets包：System.IdentityModel.Tokens.Jwt

這裏我們根據IdentityModel.Tokens.Jwt文檔給我們提供的幫助類，提供了方法WriteToken創建Token，根據參數SecurityToken，可以實例化，JwtSecurityToken，指定可選參數的類。

        /// <summary>
        /// Initializes a new instance of the <see cref="JwtSecurityToken"/> class specifying optional parameters.
        /// </summary>
        /// <param name="issuer">If this value is not null, a { iss, 'issuer' } claim will be added, overwriting any 'iss' claim in 'claims' if present.</param>
        /// <param name="audience">If this value is not null, a { aud, 'audience' } claim will be added, appending to any 'aud' claims in 'claims' if present.</param>
        /// <param name="claims">If this value is not null then for each <see cref="Claim"/> a { 'Claim.Type', 'Claim.Value' } is added. If duplicate claims are found then a { 'Claim.Type', List&lt;object&gt; } will be created to contain the duplicate values.</param>
        /// <param name="expires">If expires.HasValue a { exp, 'value' } claim is added, overwriting any 'exp' claim in 'claims' if present.</param>
        /// <param name="notBefore">If notbefore.HasValue a { nbf, 'value' } claim is added, overwriting any 'nbf' claim in 'claims' if present.</param>
        /// <param name="signingCredentials">The <see cref="SigningCredentials"/> that will be used to sign the <see cref="JwtSecurityToken"/>. See <see cref="JwtHeader(SigningCredentials)"/> for details pertaining to the Header Parameter(s).</param>
        /// <exception cref="ArgumentException">If 'expires' &lt;= 'notbefore'.</exception>
        public JwtSecurityToken(string issuer = null, string audience = null, IEnumerable<Claim> claims = null, DateTime? notBefore = null, DateTime? expires = null, SigningCredentials signingCredentials = null)
        {
            if (expires.HasValue && notBefore.HasValue)
            {
                if (notBefore >= expires)
                    throw LogHelper.LogExceptionMessage(new ArgumentException(LogHelper.FormatInvariant(LogMessages.IDX12401, expires.Value, notBefore.Value)));
            }

            Payload = new JwtPayload(issuer, audience, claims, notBefore, expires);
            Header = new JwtHeader(signingCredentials);
            RawSignature = string.Empty;
        }

這樣，我們可以根據參數指定內容：

1. string iss = "JWTBearer.Auth";  // 定義發行人
2. string aud = "api.auth";       //定義受眾人audience
3. IEnumerable<Claim> claims = new Claim[]
{
new Claim(JwtClaimTypes.Id,"1"),
new Claim(JwtClaimTypes.Name,"i3yuan"),
};//定義許多種的聲明Claim,信息存儲部分,Claims的實體一般包含用戶和一些元數據
4. var nbf = DateTime.UtcNow;  //notBefore  生效時間
5. var Exp = DateTime.UtcNow.AddSeconds(1000);  //expires 過期時間
6. string sign = "q2xiARx$4x3TKqBJ"; //SecurityKey 的長度必須 大於等於 16個字符
 var secret = Encoding.UTF8.GetBytes(sign);
 var key = new SymmetricSecurityKey(secret);
 var signcreds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);

好了，通過以上填充參數內容，進行傳參賦值得到，完整代碼如下：

新增AuthController.cs控制器：

    [HttpGet]
    public IActionResult GetToken()
    {
        try
        {
            //定義發行人issuer
            string iss = "JWTBearer.Auth";
            //定義受眾人audience
            string aud = "api.auth";

            //定義許多種的聲明Claim,信息存儲部分,Claims的實體一般包含用戶和一些元數據
            IEnumerable<Claim> claims = new Claim[]
            {
                new Claim(JwtClaimTypes.Id,"1"),
                new Claim(JwtClaimTypes.Name,"i3yuan"),
            };
            //notBefore  生效時間
            // long nbf =new DateTimeOffset(DateTime.Now).ToUnixTimeSeconds();
            var nbf = DateTime.UtcNow;
            //expires   //過期時間
            // long Exp = new DateTimeOffset(DateTime.Now.AddSeconds(1000)).ToUnixTimeSeconds();
            var Exp = DateTime.UtcNow.AddSeconds(1000);
            //signingCredentials  簽名憑證
            string sign = "q2xiARx$4x3TKqBJ"; //SecurityKey 的長度必須 大於等於 16個字符
            var secret = Encoding.UTF8.GetBytes(sign);
            var key = new SymmetricSecurityKey(secret);
            var signcreds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);
            var jwt = new JwtSecurityToken(issuer: iss, audience: aud, claims:claims,notBefore:nbf,expires:Exp, signingCredentials: signcreds);
		    var JwtHander = new JwtSecurityTokenHandler();
            var token = JwtHander.WriteToken(jwt);
            return Ok(new
            {
                access_token = token,
                token_type = "Bearer",
            });
        }
        catch (Exception ex)
        {
            throw;
        }
    }

注意：
1.SecurityKey 的長度必須 大於等於 16個字符，否則生成會報錯。（可通過在線隨機生成密鑰）

5. 運行

訪問獲取Token方法，獲取得到access_token:

再訪問，授權資源接口，可以發現，再沒有添加請求頭token值的情況下，返回了401沒有權限。

這次，在請求頭通過Authorization加上之前獲取的token值后，再次進行訪問，發現已經可以獲取訪問資源控制器，並返回對應的數據。

6.擴展說明

在HTTP標準驗證方案中，我們比較熟悉的是”Basic”和”Digest”，前者將用戶名密碼使用BASE64編碼後作為驗證憑證，後者是Basic的升級版，更加安全，因為Basic是明文傳輸密碼信息，而Digest是加密後傳輸。

一、Basic基礎認證

Basic認證是一種較為簡單的HTTP認證方式，客戶端通過明文（Base64編碼格式）傳輸用戶名和密碼到服務端進行認證，通常需要配合HTTPS來保證信息傳輸的安全。

客戶端請求需要帶Authorization請求頭，值為“Basic xxx”，xxx為“用戶名:密碼”進行Base64編碼後生成的值。 若客戶端是瀏覽器，則瀏覽器會提供一個輸入用戶名和密碼的對話框，用戶輸入用戶名和密碼后，瀏覽器會保存用戶名和密碼，用於構造Authorization值。當關閉瀏覽器后，用戶名和密碼將不再保存。

憑證為“YWxhzGRpbjpvcGVuc2VzYWl1”，是通過將“用戶名:密碼”格式的字符串經過的Base64編碼得到的。而Base64不屬於加密範疇，可以被逆向解碼，等同於明文，因此Basic傳輸認證信息是不安全的。

Basic基礎認證圖示：

缺陷匯總
1.用戶名和密碼明文（Base64）傳輸，需要配合HTTPS來保證信息傳輸的安全。
2.即使密碼被強加密，第三方仍可通過加密后的用戶名和密碼進行重放攻擊。
3.沒有提供任何針對代理和中間節點的防護措施。
4.假冒服務器很容易騙過認證，誘導用戶輸入用戶名和密碼。

二、Digest摘要認證

Digest認證是為了修復基本認證協議的嚴重缺陷而設計的，秉承“絕不通過明文在網絡發送密碼”的原則，通過“密碼摘要”進行認證，大大提高了安全性。

Digest認證步驟如下：
第一步：客戶端訪問Http資源服務器。由於需要Digest認證，服務器返回了兩個重要字段nonce（隨機數）和realm。
第二步：客戶端構造Authorization請求頭，值包含username、realm、nouce、uri和response的字段信息。其中，realm和nouce就是第一步返回的值。nouce只能被服務端使用一次。uri(digest-uri)即Request-URI的值，但考慮到經代理轉發后Request-URI的值可能被修改、因此實現會複製一份副本保存在uri內。response也可叫做Request-digest，存放經過MD5運算后的密碼字符串，形成響應碼。
第三步：服務器驗證包含Authorization值的請求，若驗證通過則可訪問資源。
Digest認證可以防止密碼泄露和請求重放，但沒辦法防假冒。所以安全級別較低。
Digest和Basic認證一樣，每次都會發送Authorization請求頭，也就相當於重新構造此值。所以兩者易用性都較差。

Digest認證圖示：

7.注意

1. 在進行JwtBearer認證時，在生成token之後，還需要與刷新token配合使用，因為當用戶執行了退出，修改密碼等操作時，需要讓該token無效，無法再次使用，所以，會給access_token設置一個較短的有效期間，(JwtBearer認證默認會驗證有效期，通過notBefore和expires來驗證)，當access_token過期后，可以在用戶無感知的情況下，使用refresh_token重新獲取access_token，但這就不屬於Bearer認證的範疇了，但是我們可以通過另一種方式通過IdentityServer的方式來實現，在後續中會對IdentityServer進行詳細講解。
2. 在生成token的時候，需要用的secret，主要是用來防止token被偽造與篡改。因為當token被劫取的時候，可以得到你的令牌中帶的一些個人不重要的信息明文，但不用擔心，只要你不在生成token里把私密的個人信息放出去的話，就算被動機不良的人得到，也做不了什麼事情。但是你可能會想，如果用戶自己隨便的生成一個 token ，帶上你的信息，那不就可以隨便訪問你的資源服務器了，因此這個時候就需要利用secret 來生成 token，來確保数字簽名的正確性。而且在認證授權資源，進行token解析的時候，通過微軟的源碼發現，已經幫我們封裝了方法，對secret進行了校驗了，確保了token的安全性，從而保證api資源的安全。

8.總結

1. JwtToken在認證時，無需Security token service安全令牌服務器的參与，都是基於Claim的，默認會驗證有效期，通過notBefore和expires來驗證，這在分佈式中提供給了極大便利。
2. JwtToken與平台、無言無關，在前端也可以直接解析出Claims。
3. 如果有不對的或不理解的地方，希望大家可以多多指正，提出問題，一起討論,不斷學習,共同進步。
4. 後面會對認證授權方案中的授權這一塊進行說明分享。
5. 本示例源碼地址
   參考JwtBearer源碼

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計最專業,超強功能平台可客製化

※聚甘新

作者：HelloGitHub-追夢人物

此前我們一直在操作博客文章（Post）資源，並藉此介紹了序列化器（Serializer）、視圖集（Viewset）、路由器（Router）等 django-rest-framework 提供的便利工具，藉助這些工具，就可以非常快速地完成 RESTful API 的開發。

評論（Comment）是另一種資源，我們同樣藉助以上工具來完成對評論資源的接口開發。

首先是設計評論 API 的 URL，根據 RESTful API 的設計規範，評論資源的 URL 設計為：/comments/

對評論資源的操作有獲取某篇文章下的評論列表和創建評論兩種操作，因此相應的 HTTP 請求和動作（action）對應如下：

文章評論列表 API 使用自定義的 action，放在 /post/ 接口的視圖集下；發表評論接口使用標準的 create action，需要定義單獨的視圖集。

然後需要一個序列化器，用於評論資源的序列化（獲取評論時），反序列化（創建評論時）。有了編寫文章序列化器的基礎，評論序列化器就是依葫蘆畫瓢的事。

comments/serializers.py

from rest_framework import serializers
from .models import Comment


class CommentSerializer(serializers.ModelSerializer):
    class Meta:
        model = Comment
        fields = [
            "name",
            "email",
            "url",
            "text",
            "created_time",
            "post",
        ]
        read_only_fields = [
            "created_time",
        ]
        extra_kwargs = {"post": {"write_only": True}}

注意這裏我們在 Meta 中增加了 read_only_fields、extra_kwargs 的聲明。

read_only_fields 用於指定只讀字段的列表，由於 created_time 是自動生成的，用於記錄評論發布時間，因此聲明為只讀的，不允許通過接口進行修改。

extra_kwargs 指定傳入每個序列化字段的額外參數，這裏給 post 序列化字段傳入了 write_only 關鍵字參數，這樣就將 post 聲明為只寫的字段，這樣 post 字段的值僅在創建評論時需要。而在返回的資源中，post 字段就不會出現。

首先來實現創建評論的接口，先為評論創建一個視圖集：

comments/views.py

from rest_framework import mixins, viewsets
from .models import Comment
from .serializers import CommentSerializer

class CommentViewSet(mixins.CreateModelMixin, viewsets.GenericViewSet):
    serializer_class = CommentSerializer

    def get_queryset(self):
        return Comment.objects.all()

視圖集非常的簡單，混入 CreateModelMixin 后，視圖集就實現了標準的 create action。其實 create action 方法的實現也非常簡單，我們來學習一下 CreateModelMixin 的源碼實現。

class CreateModelMixin:
    """
    Create a model instance.
    """
    def create(self, request, *args, **kwargs):
        serializer = self.get_serializer(data=request.data)
        serializer.is_valid(raise_exception=True)
        self.perform_create(serializer)
        headers = self.get_success_headers(serializer.data)
        return Response(serializer.data, status=status.HTTP_201_CREATED, headers=headers)

    def perform_create(self, serializer):
        serializer.save()

    def get_success_headers(self, data):
        try:
            return {'Location': str(data[api_settings.URL_FIELD_NAME])}
        except (TypeError, KeyError):
            return {}

核心邏輯在 create 方法：首先取到綁定了用戶提交數據的序列化器，用於反序列化。接着調用 is_valid 方法校驗數據合法性，如果不合法，會直接拋出異常（raise_exception=True）。否則就執行序列化的 save 邏輯將評論數據存入數據庫，最後返迴響應。

接着在 router 里註冊 CommentViewSet 視圖集：

router.register(r"comments", comments.views.CommentViewSet, basename="comment")

進入 API 交互後台，可以看到首頁列出了 comments 接口的 URL，點擊進入 /comments/ 后可以看到一個評論表單，在這裏可以提交評論數據與創建評論的接口進行交互。

接下來實現獲取評論列表的接口。通常情況下，我們都是只獲取某篇博客文章下的評論列表，因此我們的 API 設計成了 /posts/:id/comments/。這個接口具有很強的語義，非常符合 RESTful API 的設計規範。

由於接口位於 /posts/ 空間下，因此我們在 PostViewSet 添加自定義 action 來實現，先來看代碼：

blog/views.py

class PostViewSet(
    mixins.ListModelMixin, mixins.RetrieveModelMixin, viewsets.GenericViewSet
):
    # ...
    
    @action(
            methods=["GET"],
            detail=True,
            url_path="comments",
            url_name="comment",
            pagination_class=LimitOffsetPagination,
            serializer_class=CommentSerializer,
    )
    def list_comments(self, request, *args, **kwargs):
        # 根據 URL 傳入的參數值（文章 id）獲取到博客文章記錄
        post = self.get_object()
        # 獲取文章下關聯的全部評論
        queryset = post.comment_set.all().order_by("-created_time")
        # 對評論列表進行分頁，根據 URL 傳入的參數獲取指定頁的評論
        page = self.paginate_queryset(queryset)
        # 序列化評論
        serializer = self.get_serializer(page, many=True)
        # 返回分頁后的評論列表
        return self.get_paginated_response(serializer.data)

action 裝飾器我們在上一篇教程中進行了詳細說明，這裏我們再一次接觸到 action 裝飾器更為深入的用法，可以看到我們除了設置 methods、detail、url_path 這些參數外，還通過設置 pagination_class、serializer_class 來覆蓋原本在 PostViewSet 中設置的這些類屬性的值（例如對於分頁，PostViewSet 默認為我們之前設置的 PageNumberPagination，而這裏我們替換為 LimitOffsetPagination）。

list_comments 方法邏輯非常清晰，註釋中給出了詳細的說明。另外還可以看到我們調用了一些輔助方法，例如 paginate_queryset 對查詢集進行分頁；get_paginated_response 返回分頁后的 HTTP 響應，這些方法其實都是 GenericViewSet 提供的通用輔助方法，源碼也並不複雜，如果不用這些方法，我們自己也可以輕鬆實現，但既然 django-rest-framework 已經為我們寫好了，直接復用就行，具體的實現請大家通過閱讀源碼進行學習。

現在進入 API 交互後台，進入某篇文章的詳細接口，例如訪問 /api/posts/5/，Extra Actions 下拉框中可以看到 List comments 的選項：

點擊 List comments 即可進入這篇文章下的評論列表接口，獲取這篇文章的評論列表資源了：

關注公眾號加入交流群

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司“嚨底家”!

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※聚甘新

領域驅動設計DDD（Domain Driven Design）提出了從業務設計到代碼實現一致性的要求，不再對分析模型和實現模型進行區分。也就是說從代碼的結構中我們可以直接理解業務的設計，命名得當的話，非程序人員也可以“讀”代碼。這與微服務設計中的約定優於配置不謀而合，如果你熟悉英文，那麼直接根據包名和類名就可以直接解讀出程序開發者所構建的業務的大概意圖。

領域模型包含一些明確定義的類型：

• 實體是一個對象，它有固定的身份，具有明確定義的”連續性線索”或生命周期。通常列舉的示例是一個 Person（一個實體）。大多數系統都需要唯一地跟蹤一個 Person，無論姓名、地址或其他屬性是否更改。
• l值對象沒有明確定義的身份，而僅由它們的屬性定義。它們通常不可變，所以兩個相等的值對象始終保持相等。地址可以是與 Person 關聯的值對象。
• l集合是一個相關對象集群，這些對象被看作一個整體。它擁有一個特定實體作為它的根，並定義了明確的封裝邊界。它不只是一個列表。
• l服務用於表示不是實體或值對象的自然部分的操作或活動。

領域模型在實現時可大可小，在業務的早期，在系統比較小的情況下，它有可能是一個類。當系統做大了以後，它可能是個庫。再做更大一點的時候，它可能是一個服務，給不同的應用去調用。

要將領域元素轉換為服務，可按照以下一般準則來完成此操作：

• 使用值對象的表示作為參數和返回值，將集合和實體轉換為獨立的微服務。
• 將領域服務（未附加到集合或實體的服務）與獨立的微服務相匹配。
• 每個微服務應處理一個完整的業務功能。

領域模型又可以分為失血、貧血和充血3種。

• 失血模型：基於數據庫的領域設計方式就是典型的失血模型，只關注數據的增刪改查。
• 貧血模型：就是在domain object包含了不依賴於持久化的領域邏輯，而那些依賴持久化的領域邏輯被分離到server層。
• 充血模型：充血模型跟貧血模型差不多，不同的是如何劃分業務邏輯，就是說，約大部分業務應該放到domain object裏面，而service應該是很薄的一層。

設計原則之分層架構

同一公司使用統一應用分層，以減少開發維護學習成本。應用分層這件事情看起來很簡單，但每個程序員都有自己的一套，哪怕是初學者，所以想實施起來並非那麼容易。

最早接觸分層架構的應該是我們最熟悉的MVC（Model-View-Controller）架構，將應用分成了模型、視圖和控制層，可以說引導了絕大多數開發者，而我們現在的應用中非常多的包括框架，架構設計都使用此模式。這后又演化出了MVP（Model-View-Presenter）和MVVM（Model-View-ViewModel）。這些可以說都是隨着技術的不斷髮展，為了應對不同場景所演化出來的模型。而微服務的每個架構都可以再細分成領域模型，下面看一下經典的領域模型架構。

它包括了Domain，Service Layer和Repositories。核心實體（Entity）和值對象（Value Object）應該在Domain層，定義的領域服務（Domain Service）在Service Layer，而針對實體和值對象的存儲和查詢邏輯都應該在Repositories層。值得注意的是，不要把Entity的屬性和行為分離到Domain和Service兩層中去實現，即所謂的貧血模型，事實證明這樣的實現方式會造成很大的維護問題。基於這種設計，工程的結構可以構造為：

– MicroService-Sample/src/

    domain

    gateways

    interface

    repositories

    services

當然，在微服務的架構中，每個微服務不必嚴格遵照這樣的規定，切忌死搬硬套，最重要的是理解，在不同的業務場合，架構的設計可以適當的做調整，畢竟適合的架構一定要具有靈活性。

分層的原則包括：

• 文件夾分層法

應用分層採用文件夾方式的優點是可大可小、簡單易用、統一規範，可以包括 5 個項目，也可以包括 50 個項目，以滿足所有業務應用的多種不同場景。

• 調用規約

在開發過程中，需要遵循分層架構的約束，禁止跨層次的調用。

• 下層為上層服務

以用戶為中心，以目標為導向。上層（業務邏輯層）需要什麼，下層（數據訪問層）提供什麼，而不是下層（數據訪問層）有什麼，就向上層（業務邏輯層）提供什麼。

• 實體層規約

Entity是數據表對象，不是數據訪問層對象；DTO 是網絡傳輸對象，不是表現層對象；BO 是內存計算邏輯對象，不是業務邏輯層對象，不是只能給業務邏輯層使用 。如果僅限定在本層訪問，則導致單個應用內大量沒有價值的對象轉換。以用戶為中心來設計實體類，可以減少無價值重複對象和無用轉換。

• U 型訪問

下行時表現層是 Input，業務邏輯層是 Process，數據訪問層是 Output。上行時數據訪問層是 Input，業務邏輯層是 Process,  表現層就 Output。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※聚甘新