BasicAuth認證 gin框架提供 與Go

2021-08-21 09:12:09 字數 4202 閱讀 1831

basic auth是一種開放平台認證方式,簡單的說就是需要你輸入使用者名稱和密碼才能繼續訪問。bath auth是其中一種認證方式,另一種是oauth。

basic auth認證處理簡單幾乎沒有什麼優點了,最大的缺點就是安全性低。不用說,oauth認證方式克服了basic auth認證的所有缺點,並且也是目前廣泛應用的。

gin框架提供了bath auth認證中介軟體,我們來看看該怎麼玩。

首先是服務端**:

package main

import

"gopkg.in/gin-gonic/gin.v1"

var secrets = gin.h,

"austin": gin.h,

"lena": gin.h,

}func getsecrets(c *gin.context) )

} else )

}}func main() ))

authorized.get("/secrets", getsecrets)

r.run(":8080")

}

讓我們從main函式開始。group函式註冊了乙個群組路由,gin.basicauth就是中介軟體,它的引數gin.accounts其實是乙個map[string]string型別的對映,這裡是用來記錄使用者名稱和密碼。

然後在路由/admin之下,又註冊了/secrets路由,所以他的完整路由應該是/admin/secrets。處理器是getsecrets函式。

getsecrets函式中,首先從上下文gin.context中獲取使用者名稱。gin.authuserkey是乙個字串常量,定義如下:

const authuserkey = "user"
這裡獲取的使用者名稱就是你訪問這個url時輸入的使用者名稱,後台會驗證密碼,如果使用者名稱和密碼都對上了,認證才會成功。

接下來會利用獲得的使用者名稱去secrets結構中查詢使用者資訊。gin.h是乙個map[string]inte***ce{}的對映。最後通過json返回查詢結果。

現在萬事具備,讓我們用在瀏覽器中輸入localhost:8080/admin/secrets進行訪問,不出意外你會看到乙個提示框,要你輸入使用者名稱和密碼。使用者名稱輸入foo,密碼輸入bar。然後你就能看到乙個關於foo的資訊的json串了。

下面讓我們用curl試試。開啟powershell,輸入curl localhost:8080/admin/secrets,然後帥氣的回車。

為什麼什麼也沒有?

再次輸入curl -i localhost:8080/admin/secrets回車,檢視響應頭,得到的居然是乙個401的響應。這是很正常的,應為你並沒有提供任何有關使用者名稱和密碼的資訊,所以認證必然是失敗的,認證失敗就會得到401的響應。

我們可以看看basicauth函式的源**:

func basicauth(accounts accounts) handlerfunc
繼續追查basicauthforrealm函式:

func basicauthforrealm(accounts accounts, realm string) handlerfunc  else 

}}

讓我們省略一些無關緊要的細節。這裡的accounts就是我們呼叫basicauth函式時帶入的使用者名稱-密碼對映,這裡需要用來進行身份驗證。最後返回了乙個匿名函式,這個匿名函式就是中介軟體。

在匿名函式中首先會去請求頭中去查詢authorization請求首部,如果找到了,就呼叫set函式把這個請求首部中的使用者名稱設定到上下文,也就是gin.context中。無獨有偶,這裡我們又看到了authuserkey,現在你知道為什麼在getsecrets函式中我們要用它去獲取使用者名稱了吧。需要注意的是searchcredential函式除了獲取使用者名稱還會進行密碼驗證。

如果請求頭中沒有authorization請求首部,那麼恭喜,你將毫無懸念的得到401響應。

所以,當我們使用curl訪問時,需要設定一下請求頭。但是問題又來了,該如何設定請求頭呢?

不要緊,其實想通過驗證只需要在訪問時提供使用者名稱和密碼就行了,這一要求通過url也是可以辦到的。如下:

curl

foo:bar

@localhost:8080/admin/secrets

這次就能看到返回的json串了。是這樣子的:

,"user":"foo"

}

既然這樣,我們不妨再看看這樣訪問時curl傳送給伺服器的請求頭是怎樣的。通過-v選項能達到這一目的:

curl

-vfoo

:bar

@localhost:8080/admin/secrets

這是我們將得到如下的輸出:

,"user":"foo"}>符號後面的是請求,<符號後面的是響應。我們注意到請求頭中有這樣一行請求首部:

authorization: basic zm9vomjhcg==
這正是我們苦苦尋覓的驗證資訊!不過basic後面一串亂碼又是什麼鬼?

如果想通過設定請求頭進行驗證,按照上面的模式設定請求頭就可以啦。下面讓我們用這種方式來獲取austin的秘密。首先需要訪問base64編碼**,得到austin:1234經過編碼後的內容,然後在powershell中輸入以下命令:

curl -v

-h'authorization: basic yxvzdgluojeymzq=' localhost:8080/admin/secrets

-h用來向請求頭新增自定義字段。再次帥氣的回車,你將得到以下內容:

,"user":"austin"}成功獲取austin的秘密,是不是666。

最後總結一下認證的三種方式:

通過瀏覽器訪問,輸入使用者名稱和密碼;

通過url提供使用者名稱和密碼,如:user:password@localhost:8080/admin/secrets;

通過在請求頭中新增authorization字段提供使用者名稱和密碼,需要經過base64編碼。

iOS 開發之Basic Auth認證

一種是basic auth,一種是oauth 現在普遍還是使用oauth的多,而使用basic auth認證的少,badic auth認證方式開發和除錯簡單,沒有複雜的頁面跳轉邏輯和互動過程,更利於發起方控制。然而缺點就是安全性更低,不過也沒事,我們可以使用https安全加密協議,這樣才更安全。我使...

Etcd安全配置之Basic Auth認證

中小團隊落地配置中心詳解 文章中我們介紹了如何基於etcd confd構建配置中心,最後提到etcd的安全問題時說了可以使用賬號密碼認證以達到安全訪問的目的,究竟該如何開啟認證以及怎麼設計許可權訪問呢?本文將為你詳細解讀 etcd v2以上的版本才支援許可權認證,且僅支援basic auth etc...

Etcd安全配置之Basic Auth認證

etcd通過使用者 user 角色 role 許可權的方式來控制訪問,使用者關聯角色,角色擁有許可權,從而使用者也就擁有了相應的許可權 etcd預設沒有啟用認證機制,只要能連線etcd服務就擁有所有的許可權,還是非常危險的,另一種安全的訪問方式是開啟ssl,只有使用受信任的證書才能訪問資料 etcd...