gofuntoken怎么打不開(kāi)

token驗(yàn)證是一種web常用的身份驗(yàn)證手段。

創(chuàng)新互聯(lián)不只是一家網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司；我們對(duì)營(yíng)銷、技術(shù)、服務(wù)都有自己獨(dú)特見(jiàn)解，公司采取“創(chuàng)意+綜合+營(yíng)銷”一體化的方式為您提供更專業(yè)的服務(wù)！我們經(jīng)歷的每一步也許不一定是最完美的，但每一步都有值得深思的意義。我們珍視每一份信任，關(guān)注我們的成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)質(zhì)量和服務(wù)品質(zhì)，在得到用戶滿意的同時(shí)，也能得到同行業(yè)的專業(yè)認(rèn)可，能夠?yàn)樾袠I(yè)創(chuàng)新發(fā)展助力。未來(lái)將繼續(xù)專注于技術(shù)創(chuàng)新，服務(wù)升級(jí)，滿足企業(yè)一站式營(yíng)銷型網(wǎng)站需求，讓再小的成都品牌網(wǎng)站建設(shè)也能產(chǎn)生價(jià)值！

在這里不討論它的具體實(shí)現(xiàn)，需要在golang里實(shí)現(xiàn)token驗(yàn)證，Web框架是Gin當(dāng)然這與框架沒(méi)有關(guān)系步驟如下從request獲取tokenstring，將tokenstring轉(zhuǎn)化為未解密的token對(duì)象。

說(shuō)明：

將未解密的token對(duì)象解密得到解密后的token對(duì)象，從解密后的token對(duì)象里取參數(shù)，獲取解密后的token，該函數(shù)根據(jù)request，獲得tokenstring，并轉(zhuǎn)為未解密token對(duì)象，解密后得到解密token對(duì)象。

import github.com/dgrijalva/jwt-go/requestrequest.ParseFromRequestreq *http.Request, extractor Extractor, keyFunc jwt.Keyfuncreq即為http請(qǐng)求。

extractor 是一個(gè)實(shí)現(xiàn)了Extractor接口的對(duì)象，該接口需要實(shí)現(xiàn)的函ExtractToken*http.Request string, error，用于從http請(qǐng)求中提取tokenstring，keyFunc是一個(gè)函數(shù)，需要接受一個(gè)未解密的token。

并返回Secretkey的字節(jié)和錯(cuò)誤信息func GetTokenr *http.Request，token *jwt.Token, err error? 由request獲取token，t := T t是已經(jīng)實(shí)現(xiàn)extract接口的對(duì)象，對(duì)request進(jìn)行處理得到tokenString并生成為解密的token。

Vault的基本用法

介紹Vault的基本用法，包括安裝和數(shù)據(jù)存取

vault是使用go語(yǔ)言開(kāi)發(fā)的開(kāi)源工具，必須先安裝golang

這個(gè)例子中，我們使用zookeeper作為后段存儲(chǔ)。

因?yàn)樾枰С侄鄠€(gè)vault實(shí)例，不能使用本地文件系統(tǒng)存儲(chǔ)；另外使用zookeeper作為存儲(chǔ)，必須配置api_addr參數(shù)。

初始化只需要整個(gè)vault集群執(zhí)行一次就行；如果有多個(gè)vault實(shí)例，只要任何一個(gè)，只需要執(zhí)行一次即可。

會(huì)生成5個(gè)unseal key和一個(gè)root token；其中unseal key下面就會(huì)用到，必須存好不可丟失，而root token則是一個(gè)超級(jí)用戶token，必須妥善保管，一般用它來(lái)做系統(tǒng)配置，然后簽出用戶token。

Rest API:

前面我們生成了5個(gè)unseal key，這是vault的缺省配置，一共生成5個(gè)unseal key，每次解封必須使用其中的三個(gè)。(這5和3可以在初始化的時(shí)候配置)

解封操作需要在每一個(gè)實(shí)例的每次啟動(dòng)時(shí)執(zhí)行。

Rest API

三次解封，在查看結(jié)果：

Rest API

查看secrets激活狀態(tài)

在能夠進(jìn)行secret的讀寫(xiě)操作之前，必須先激活secrets引擎。

激活操作也初始化一樣，整個(gè)集群只需要第一次啟動(dòng)的時(shí)候執(zhí)行一次就行。

這里用到了TOKEN，是在vault初始化的時(shí)候生成的。

Rest API

Rest API

這個(gè)地方需要注意的是，雖然每個(gè)path(secert/mypath)下面有多個(gè)key/value對(duì)，但他們都是值，實(shí)際上只有path才是唯一的key，這就是說(shuō)不能對(duì)一個(gè)path下面的單獨(dú)key進(jìn)行修改，vault只能覆蓋整個(gè)path的內(nèi)容，例如：

Rest API

上面這兩條命令，后面一條可能是想修改mykey1的值，保留mykey2的值，但實(shí)際情況會(huì)覆蓋前面一條的所有值，即mykey2會(huì)丟掉。

15 Go 鑒權(quán)（一）：鑒權(quán)機(jī)制概述

在現(xiàn)代web開(kāi)發(fā)中，系統(tǒng)鑒權(quán)服務(wù)已是基本標(biāo)配模塊，有些開(kāi)發(fā)框架甚至內(nèi)置了鑒權(quán)模塊的實(shí)現(xiàn)，或者提供一些鑒權(quán)的工具類，然而鑒權(quán)的方式也分為多種，了解各種鑒權(quán)方式的特點(diǎn)及使用場(chǎng)景可以幫助我們構(gòu)建更健壯的web系統(tǒng)。以下列出四種常見(jiàn)的鑒權(quán)方式，我們來(lái)認(rèn)識(shí)一下：

HTTP 基本身份驗(yàn)證，允許客戶端在標(biāo)準(zhǔn)的 HTTP 頭中發(fā)送用戶名和密碼。服務(wù)端可以驗(yàn)證這些信息，并確認(rèn)客戶端是否有權(quán)訪問(wèn)服務(wù)。這樣做的好處在于，這是一種非常容易理解且得到廣泛支持的協(xié)議。問(wèn)題在于，通過(guò) HTTP 有很高的風(fēng)險(xiǎn)，因?yàn)橛脩裘兔艽a并沒(méi)有以安全的方式發(fā)送。任何中間方都可以看到 HTTP 頭的信息并讀取里面的數(shù)據(jù)。因此，HTTP 基本身份驗(yàn)證通常應(yīng)該通過(guò) HTTPS 進(jìn)行通信。

當(dāng)使用 HTTPS 時(shí)，客戶端獲得強(qiáng)有力的保證，它所通信的服務(wù)端就是客戶端想要通信的服務(wù)端。它給予我們額外的保護(hù)，避免人們竊聽(tīng)客戶端和服務(wù)端之間的通信，或篡改有效負(fù)載。

服務(wù)端需要管理自己的SSL證書(shū)，當(dāng)需要管理多臺(tái)機(jī)器時(shí)會(huì)出現(xiàn)問(wèn)題。一些組織自己承擔(dān)簽發(fā)證書(shū)的過(guò)程，這是一個(gè)額外的行政和運(yùn)營(yíng)負(fù)擔(dān)。管理這方面的自動(dòng)化工具遠(yuǎn)不夠成熟，使用它們后你會(huì)發(fā)現(xiàn)，需要自己處理的事情就不止證書(shū)簽發(fā)了。自簽名證書(shū)不容易撤銷，因此需要對(duì)災(zāi)難情景有更多的考慮?？纯茨闶欠衲軌虮苊庾院灻员荛_(kāi)所有的這些工作。

SSL 之上的流量不能被反向代理服務(wù)器（比如 Varnish 或 Squid）所緩存，這是使用 HTTPS 的另一個(gè)缺點(diǎn)。這意味著，如果你需要緩存信息，就不得不在服務(wù)端或客戶端內(nèi)部實(shí)現(xiàn)。你可以在負(fù)載均衡中把 Https 的請(qǐng)求轉(zhuǎn)成 Http 的請(qǐng)求，然后在負(fù)載均衡之后就可以使用緩存了。

還需要考慮，如果我們已經(jīng)在使用現(xiàn)成的 SSO 方案（比如包含用戶名密碼信息的 SAML），該怎么辦。我們想要基本身份驗(yàn)證使用同一套認(rèn)證信息，然后在同一個(gè)進(jìn)程里頒發(fā)和撤銷嗎？讓服務(wù)與實(shí)現(xiàn) SSO 所使用的那個(gè)目錄服務(wù)進(jìn)行通信即可做到這一點(diǎn)?；蛘?，我們可以在服務(wù)內(nèi)部存儲(chǔ)用戶名和密碼，但需要承擔(dān)存在重復(fù)行為的風(fēng)險(xiǎn)。

注意：使用這種方法，服務(wù)器只知道客戶端有用戶名和密碼。我們不知道這個(gè)信息是否來(lái)自我們期望的機(jī)器；它可能來(lái)自網(wǎng)絡(luò)中的其他人。

HTTP 基本身份驗(yàn)證是一種簡(jiǎn)單但不那么安全的認(rèn)證方式，不太建議用于公開(kāi)的商業(yè)應(yīng)用，在此便不再展開(kāi)，我們關(guān)注以下幾種認(rèn)證方式。

http協(xié)議是一種無(wú)狀態(tài)的協(xié)議，如果沒(méi)有任何認(rèn)證機(jī)制，服務(wù)端對(duì)任何客戶端的請(qǐng)求都是無(wú)差別的。在Web2.0時(shí)代，為了加強(qiáng)B/S交互的安全性，衍生出了Session-Cookie鑒權(quán)機(jī)制，通過(guò)在服務(wù)端開(kāi)啟會(huì)話，客戶端存儲(chǔ)SessionID，在每次請(qǐng)求時(shí)通過(guò)cookie傳輸SessionID的形式實(shí)現(xiàn)服務(wù)端基本鑒權(quán)。

cookie是保存在本地終端的數(shù)據(jù)。cookie由服務(wù)器生成，發(fā)送給瀏覽器，瀏覽器把cookie以kv形式保存到某個(gè)目錄下的文本文件內(nèi)，下一次請(qǐng)求同一網(wǎng)站時(shí)會(huì)把該cookie發(fā)送給服務(wù)器。由于cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會(huì)被惡意使用，同時(shí)不會(huì)占據(jù)太多磁盤(pán)空間，所以每個(gè)域的cookie數(shù)量是有限的。

cookie的組成有：名稱(key)、值(value)、有效域(domain)、路徑(域的路徑，一般設(shè)置為全局:"")、失效時(shí)間、安全標(biāo)志(指定后，cookie只有在使用SSL連接時(shí)才發(fā)送到服務(wù)器(https))。

Session的中文翻譯是“會(huì)話”，當(dāng)用戶打開(kāi)某個(gè)web應(yīng)用時(shí)，便與web服務(wù)器產(chǎn)生一次session。服務(wù)器使用session把用戶的信息臨時(shí)保存在了服務(wù)器上，用戶離開(kāi)網(wǎng)站后session會(huì)被銷毀。這種用戶信息存儲(chǔ)方式相對(duì)cookie來(lái)說(shuō)更安全，可是session有一個(gè)缺陷：如果web服務(wù)器做了負(fù)載均衡，那么下一個(gè)操作請(qǐng)求到了另一臺(tái)服務(wù)器的時(shí)候session會(huì)丟失。

當(dāng)程序需要為某個(gè)客戶端的請(qǐng)求創(chuàng)建一個(gè)session時(shí)，服務(wù)器首先檢查這個(gè)客戶端的請(qǐng)求里是否已包含了一個(gè)session標(biāo)識(shí)（稱為SessionID），如果已包含則說(shuō)明以前已經(jīng)為此客戶端創(chuàng)建過(guò)Session，服務(wù)器就按照SessionID把這個(gè)Session檢索出來(lái)使用（檢索不到，會(huì)新建一個(gè)），如果客戶端請(qǐng)求不包含SessionID，則為此客戶端創(chuàng)建一個(gè)Session并且生成一個(gè)與此Session相關(guān)聯(lián)的SessionID，SessionID的值應(yīng)該是一個(gè)既不會(huì)重復(fù)，又不容易被找到規(guī)律以仿造的字符串，這個(gè)SessionID將被在本次響應(yīng)中返回給客戶端保存。

保存這個(gè)SessionID的方式可以采用Cookie，這樣在交互過(guò)程中瀏覽器可以自動(dòng)的按照規(guī)則把這個(gè)標(biāo)識(shí)發(fā)揮給服務(wù)器。一般這個(gè)Cookie的名字都是類似于SEEESIONID。但Cookie可以被人為的禁止，則必須有其他機(jī)制以便在Cookie被禁止時(shí)仍然能夠把SessionID傳遞回服務(wù)器。

客戶端第一次發(fā)送請(qǐng)求給服務(wù)器，此時(shí)服務(wù)器啟動(dòng)Session會(huì)話，產(chǎn)生一個(gè)唯一的SessionID，并通過(guò)Response的SetCookie返回給客戶端，保存于客戶端(一般為瀏覽器)，并與一個(gè)瀏覽器窗口對(duì)應(yīng)著,由于HTTP協(xié)議的特性，這一次Request-Response

后連接就斷開(kāi)了。以后此客戶端再發(fā)送請(qǐng)求給服務(wù)器的時(shí)候，就會(huì)在請(qǐng)求Request頭中攜帶cookie,由于cookie中帶有Key為sessionID的數(shù)據(jù),所以服務(wù)器就知道這是剛才那個(gè)客戶端。

正如我們前面所討論的，如果擔(dān)心用戶名和密碼被泄露，HTTP基本身份驗(yàn)證使用普通 HTTP 并不是非常明智的。傳統(tǒng)的替代方式是使用HTTPS路由通信，但也有一些缺點(diǎn)。除了需要管理證書(shū)，HTTPS通信的開(kāi)銷使得服務(wù)器壓力增加，而且通信難以被輕松地緩存。另外Session-Cookie機(jī)制也會(huì)有被客戶限制的隱患，如果用戶禁用Cookie則必須由其它方式實(shí)現(xiàn)鑒權(quán)。

所謂Token，即令牌?？蛻舳诵枰b權(quán)訪問(wèn)私人信息時(shí)，會(huì)首次向服務(wù)端發(fā)送身份驗(yàn)證信息（如用戶名、密碼），服務(wù)端校驗(yàn)正確后會(huì)根據(jù)一定的加密算法生成Token令牌發(fā)放給客戶端，此后客戶端只需通過(guò)Token，服務(wù)端只需驗(yàn)證Token就可識(shí)別客戶并進(jìn)行交互，Token可存放于HTTP Header也可存放與Cookie。

以上為一個(gè)簡(jiǎn)單的Token鑒權(quán)過(guò)程。

關(guān)于Token機(jī)制，業(yè)界有一種叫JWT（JsonWebToken）的實(shí)現(xiàn)機(jī)制，下面我們來(lái)了解JWT。

JWT.io 對(duì)JSON Web Tokens進(jìn)行了很好的介紹，

國(guó)內(nèi)阮一峰的 《JSON Web Token 入門(mén)教程》 也講得非常好懂，可以出門(mén)右拐了解一下。

簡(jiǎn)而言之，它是一個(gè)簽名的JSON對(duì)象，可以執(zhí)行一些有用的操作（例如，身份驗(yàn)證）。它是一組字串，分Header（頭部）、Payload（負(fù)載）、Signature（簽名）三部分，由'.'號(hào)連接，看起來(lái)就像下面這樣：

用戶發(fā)送認(rèn)證信息給服務(wù)端后，服務(wù)端通過(guò)JWT生成規(guī)則，生成JWT字串作為T(mén)oken發(fā)放給用戶，用戶以后每次訪問(wèn)都在HTTP Header攜帶JWT字串，已達(dá)到鑒權(quán)目的。由于其內(nèi)部攜帶用戶信息，部分使用者已經(jīng)發(fā)現(xiàn)其安全隱患，但其安全度不至于太過(guò)容易破解，在移動(dòng)應(yīng)用中的鑒權(quán)機(jī)制使用較多，除此之外，一些分布式的微服務(wù)應(yīng)用也通過(guò)JWT進(jìn)行模塊間的鑒權(quán)，還是有一定的使用場(chǎng)景的。

Go開(kāi)源社區(qū)已有比較成熟的JWT包實(shí)現(xiàn)： jwt-go ，內(nèi)附有JWT編解碼的使用用例，還是很好懂的，感興趣的可get來(lái)使用。在另一篇中也做了Go 使用JWT鑒權(quán)的示例： 《Go 鑒權(quán)（三）：JWT》 ,感興趣可閱讀以下，自己也在項(xiàng)目中實(shí)踐一下。

OAUTH協(xié)議為用戶資源的授權(quán)提供了一個(gè)安全的、開(kāi)放而又簡(jiǎn)易的標(biāo)準(zhǔn)。同時(shí)，任何第三方都可以使用OAUTH認(rèn)證服務(wù)，任何服務(wù)提供商都可以實(shí)現(xiàn)自身的OAUTH認(rèn)證服務(wù)，因而OAUTH是開(kāi)放的。

OpenID Connect 是 OAuth 2.0 具體實(shí)現(xiàn)中的一個(gè)標(biāo)準(zhǔn)。它使用簡(jiǎn)單的 REST 調(diào)用，因?yàn)樘岣吡似湟子眯?。?duì)于一個(gè)面向公眾的網(wǎng)站，你或許可以使用Google、Facebook、Github等作為提供者，國(guó)內(nèi)可以使用QQ、微信、淘寶等作為提供者。但對(duì)于內(nèi)部系統(tǒng)，或?qū)τ跀?shù)據(jù)需要有更多控制權(quán)的系統(tǒng)而言，你會(huì)希望有自己的內(nèi)部身份提供者。

OAuth2.0有四種授權(quán)模式，具體可看阮一峰的 《理解OAuth2.0》 ,其內(nèi)容非常詳細(xì)且好理解。

我們這里說(shuō)一下最完整的授權(quán)碼模式：

以上為OAuth2.0的認(rèn)證過(guò)程。

各大廠都有提供基于OAuth2.0的三方授權(quán)服務(wù)，如QQ、微信、淘寶等等，有需要可移步到各自的開(kāi)放平臺(tái)查看文檔，大都有提供Go的接口實(shí)現(xiàn)；另你也可參考使用Go官方提供實(shí)現(xiàn)的包 ，里面包含多數(shù)熱門(mén)的OAuth客戶端。

推薦使用 這個(gè)開(kāi)源項(xiàng)目，幫助你構(gòu)建自己的OAuth服務(wù)

將 github 設(shè)為私有倉(cāng)庫(kù)

第一步 : 生成token 「如果不是項(xiàng)目的構(gòu)建者，問(wèn)項(xiàng)目負(fù)責(zé)人獲取」

第二步 : token 設(shè)置到請(qǐng)求頭中

第三步 : 配置git將請(qǐng)求從ssh轉(zhuǎn)換為http

第四步 : 指定域名為私有倉(cāng)庫(kù)

第五步 : 檢查配置

執(zhí)行 cat ~/.gitconfig

執(zhí)行 go env

確認(rèn)配置成功

第六步 : 測(cè)試配置結(jié)果