golang驗證,golang驗證系統

本文目錄一覽：

• 1、請教，golang中的hmac驗證應該怎樣寫
• 2、15 Go 鑒權（一）：鑒權機制概述
• 3、深入理解golang
• 4、用go語言怎麼實現登錄界面的驗證
• 5、golang jwt鑒權分析

請教，golang中的hmac驗證應該怎樣寫

package main

import (

“crypto/hmac”

“crypto/sha1”

“fmt”

“io”

)

func main() {

//sha1

h := sha1.New()

io.WriteString(h, “aaaaaa”)

fmt.Printf(“%x\n”, h.Sum(nil))

//hmac ,use sha1

key := []byte(“123456”)

mac := hmac.New(sha1.New, key)

mac.Write([]byte(“aaaaaa”))

fmt.Printf(“%x\n”, mac.Sum(nil))

}

15 Go 鑒權（一）：鑒權機制概述

在現代web開發中，系統鑒權服務已是基本標配模塊，有些開發框架甚至內置了鑒權模塊的實現，或者提供一些鑒權的工具類，然而鑒權的方式也分為多種，了解各種鑒權方式的特點及使用場景可以幫助我們構建更健壯的web系統。以下列出四種常見的鑒權方式，我們來認識一下：

HTTP 基本身份驗證，允許客戶端在標準的 HTTP 頭中發送用戶名和密碼。服務端可以驗證這些信息，並確認客戶端是否有權訪問服務。這樣做的好處在於，這是一種非常容易理解且得到廣泛支持的協議。問題在於，通過 HTTP 有很高的風險，因為用戶名和密碼並沒有以安全的方式發送。任何中間方都可以看到 HTTP 頭的信息並讀取裏面的數據。因此，HTTP 基本身份驗證通常應該通過 HTTPS 進行通信。

當使用 HTTPS 時，客戶端獲得強有力的保證，它所通信的服務端就是客戶端想要通信的服務端。它給予我們額外的保護，避免人們竊聽客戶端和服務端之間的通信，或篡改有效負載。

服務端需要管理自己的SSL證書，當需要管理多台機器時會出現問題。一些組織自己承擔簽發證書的過程，這是一個額外的行政和運營負擔。管理這方面的自動化工具遠不夠成熟，使用它們後你會發現，需要自己處理的事情就不止證書籤發了。自簽名證書不容易撤銷，因此需要對災難情景有更多的考慮。看看你是否能夠避免自簽名，以避開所有的這些工作。

SSL 之上的流量不能被反向代理服務器（比如 Varnish 或 Squid）所緩存，這是使用 HTTPS 的另一個缺點。這意味着，如果你需要緩存信息，就不得不在服務端或客戶端內部實現。你可以在負載均衡中把 Https 的請求轉成 Http 的請求，然後在負載均衡之後就可以使用緩存了。

還需要考慮，如果我們已經在使用現成的 SSO 方案（比如包含用戶名密碼信息的 SAML），該怎麼辦。我們想要基本身份驗證使用同一套認證信息，然後在同一個進程里頒發和撤銷嗎？讓服務與實現 SSO 所使用的那個目錄服務進行通信即可做到這一點。或者，我們可以在服務內部存儲用戶名和密碼，但需要承擔存在重複行為的風險。

注意：使用這種方法，服務器只知道客戶端有用戶名和密碼。我們不知道這個信息是否來自我們期望的機器；它可能來自網絡中的其他人。

HTTP 基本身份驗證是一種簡單但不那麼安全的認證方式，不太建議用於公開的商業應用，在此便不再展開，我們關注以下幾種認證方式。

http協議是一種無狀態的協議，如果沒有任何認證機制，服務端對任何客戶端的請求都是無差別的。在Web2.0時代，為了加強B/S交互的安全性，衍生出了Session-Cookie鑒權機制，通過在服務端開啟會話，客戶端存儲SessionID，在每次請求時通過cookie傳輸SessionID的形式實現服務端基本鑒權。

cookie是保存在本地終端的數據。cookie由服務器生成，發送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內，下一次請求同一網站時會把該cookie發送給服務器。由於cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會佔據太多磁盤空間，所以每個域的cookie數量是有限的。

cookie的組成有：名稱(key)、值(value)、有效域(domain)、路徑(域的路徑，一般設置為全局:””)、失效時間、安全標誌(指定後，cookie只有在使用SSL連接時才發送到服務器(https))。

Session的中文翻譯是「會話」，當用戶打開某個web應用時，便與web服務器產生一次session。服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網站後session會被銷毀。這種用戶信息存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web服務器做了負載均衡，那麼下一個操作請求到了另一台服務器的時候session會丟失。

當程序需要為某個客戶端的請求創建一個session時，服務器首先檢查這個客戶端的請求里是否已包含了一個session標識（稱為SessionID），如果已包含則說明以前已經為此客戶端創建過Session，服務器就按照SessionID把這個Session檢索出來使用（檢索不到，會新建一個），如果客戶端請求不包含SessionID，則為此客戶端創建一個Session並且生成一個與此Session相關聯的SessionID，SessionID的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個SessionID將被在本次響應中返回給客戶端保存。

保存這個SessionID的方式可以採用Cookie，這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發揮給服務器。一般這個Cookie的名字都是類似於SEEESIONID。但Cookie可以被人為的禁止，則必須有其他機制以便在Cookie被禁止時仍然能夠把SessionID傳遞迴服務器。

客戶端第一次發送請求給服務器，此時服務器啟動Session會話，產生一個唯一的SessionID，並通過Response的SetCookie返回給客戶端，保存於客戶端(一般為瀏覽器)，並與一個瀏覽器窗口對應着,由於HTTP協議的特性，這一次Request-Response

後連接就斷開了。以後此客戶端再發送請求給服務器的時候，就會在請求Request頭中攜帶cookie,由於cookie中帶有Key為sessionID的數據,所以服務器就知道這是剛才那個客戶端。

正如我們前面所討論的，如果擔心用戶名和密碼被泄露，HTTP基本身份驗證使用普通 HTTP 並不是非常明智的。傳統的替代方式是使用HTTPS路由通信，但也有一些缺點。除了需要管理證書，HTTPS通信的開銷使得服務器壓力增加，而且通信難以被輕鬆地緩存。另外Session-Cookie機制也會有被客戶限制的隱患，如果用戶禁用Cookie則必須由其它方式實現鑒權。

所謂Token，即令牌。客戶端需要鑒權訪問私人信息時，會首次向服務端發送身份驗證信息（如用戶名、密碼），服務端校驗正確後會根據一定的加密算法生成Token令牌發放給客戶端，此後客戶端只需通過Token，服務端只需驗證Token就可識別客戶並進行交互，Token可存放於HTTP Header也可存放與Cookie。

以上為一個簡單的Token鑒權過程。

關於Token機制，業界有一種叫JWT（JsonWebToken）的實現機制，下面我們來了解JWT。

JWT.io 對JSON Web Tokens進行了很好的介紹，

國內阮一峰的 《JSON Web Token 入門教程》 也講得非常好懂，可以出門右拐了解一下。

簡而言之，它是一個簽名的JSON對象，可以執行一些有用的操作（例如，身份驗證）。它是一組字串，分Header（頭部）、Payload（負載）、Signature（簽名）三部分，由’.’號連接，看起來就像下面這樣：

用戶發送認證信息給服務端後，服務端通過JWT生成規則，生成JWT字串作為Token發放給用戶，用戶以後每次訪問都在HTTP Header攜帶JWT字串，已達到鑒權目的。由於其內部攜帶用戶信息，部分使用者已經發現其安全隱患，但其安全度不至於太過容易破解，在移動應用中的鑒權機制使用較多，除此之外，一些分佈式的微服務應用也通過JWT進行模塊間的鑒權，還是有一定的使用場景的。

Go開源社區已有比較成熟的JWT包實現： jwt-go ，內附有JWT編解碼的使用用例，還是很好懂的，感興趣的可get來使用。在另一篇中也做了Go 使用JWT鑒權的示例： 《Go 鑒權（三）：JWT》 ,感興趣可閱讀以下，自己也在項目中實踐一下。

OAUTH協議為用戶資源的授權提供了一個安全的、開放而又簡易的標準。同時，任何第三方都可以使用OAUTH認證服務，任何服務提供商都可以實現自身的OAUTH認證服務，因而OAUTH是開放的。

OpenID Connect 是 OAuth 2.0 具體實現中的一個標準。它使用簡單的 REST 調用，因為提高了其易用性。對於一個面向公眾的網站，你或許可以使用Google、Facebook、Github等作為提供者，國內可以使用QQ、微信、淘寶等作為提供者。但對於內部系統，或對於數據需要有更多控制權的系統而言，你會希望有自己的內部身份提供者。

OAuth2.0有四種授權模式，具體可看阮一峰的 《理解OAuth2.0》 ,其內容非常詳細且好理解。

我們這裡說一下最完整的授權碼模式：

以上為OAuth2.0的認證過程。

各大廠都有提供基於OAuth2.0的三方授權服務，如QQ、微信、淘寶等等，有需要可移步到各自的開放平台查看文檔，大都有提供Go的接口實現；另你也可參考使用Go官方提供實現的包 ，裏面包含多數熱門的OAuth客戶端。

推薦使用 這個開源項目，幫助你構建自己的OAuth服務

深入理解golang

最近三年，在工作中使用go開發了不少服務。深感go的便捷，以及它的runtime的複雜。我覺得需要定期的進行總結，因此決定寫這篇文章，也許更準確的，應該叫筆記。

最近終於解決了一個和cgo有關的問題。這個問題從發現到解決前後經歷了接近4個月，當然，和人手不足也有關係。而對於我個人而言，這個問題其實歷時2年！這得從頭說起。

在上一家公司的一個項目里，有一個服務做音視頻數據的提取，這個服務運行在嵌入式設備TX2上。音視頻提取這一關鍵功能主要利用nvidia基於gstreamer開發的插件，這個插件可以發揮nvidia gpu的硬件解碼功能。當時這個服務使用go和c混編的方式，問題的癥狀是服務運行一段時間後，不輸出音視頻數據。遺憾的是，由於疫情，項目停止，因此沒有機會繼續研究這個問題。

時間來到去年底。當前這個項目進行壓力測試，發現關鍵的語音處理服務運行一段時間後，會出現不拉流的情況，因此也沒有後續的結果輸出。癥狀和上一個項目非常像。雖然使用的第三方SDK不一樣，但同樣用了go和c混編的方式。一開始，焦點就放在go的運行時上，覺得可能是go和c相互調用的方式不對。經過合理猜測，並用測試進行驗證後，發現問題還是在第三方拉流的SDK上，它們的回調函數必須要快，否則有可能會阻塞它們的回調線程。當然，在go調用c的時候，如果耗時比較長，會對go的運行時造成一些副作用；在c回調go的時候，go的運行時也有可能阻塞c的回調線程。但go的運行時已經比較成熟，因此我覺得它對這個問題的貢獻不大。以上採用了假設-驗證的方法，主要的原因還是第三方的拉流SDK不開源。在定位問題的過程中，使用了gdb的gcore來生成堆棧；也搭建了灰度環境來進行壓力測試，以及完善監控，這些都是解決方法的一部分。

正是這一問題，促使我更多的了解go的運行時。而我看得越多，越覺得go的運行時是一個龐大的怪物。因此，抱着能了解一點是一點的心態，不斷的完善這篇筆記。

用go語言怎麼實現登錄界面的驗證

記住密碼 是用js cookie 但是你不要後台驗證么 前台每個頁面都讀取cookie 來判斷登陸狀態 wow 能實現 但是沒有實際意義

golang jwt鑒權分析

技術棧 gin+jwt

鑒權流程：

調用token生成方法GenerateToken生成token, 請求api時帶上token參數即可

token計算邏輯：

總結：md5加密賬號和密碼參數，根據賬號密碼私鑰過期時間和jwt header 分別計算hash256值，將值用.符號連接，再進行hash,結果就是token值

api 驗證token: