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也是可以辦到的。如下:
這次就能看到返回的json串了。是這樣子的:curl
foo:bar
@localhost:8080/admin/secrets
既然這樣,我們不妨再看看這樣訪問時curl傳送給伺服器的請求頭是怎樣的。通過,"user":"foo"
}
-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...