gin.Cookie() 使用
下面的小例子可以使用 postman 来请求,只要服务启动了,其实主要就是 Cookie 函数来拿到请求头的 value,用 SetCookie 函数来设置 cookie 的 value
func main() {
r := gin.Default()
r.Get("/cookie", handler.MyHandler)
r.Run(":8080")
}
func MyHandler(c *gin.Context) {
cookie_value, err := c.Cookie("my_cookie")
if err != nil {
cookie_value = "no value"
c.SetCookie("my_cookie", cookie_value, 3600, "/", "localhost", false, true)
}
c.Header("result", cookie_value)
}
gin.BasicAuth() 中间件
如下,关键是使用 secrets 的 map 可以想象是数据库中的数据,然后在某个路由分组加上这个中间件 gin.BasicAuth(),此中间件需要在访问分组路由中的接口时候都能触发这个中间件识别,再然后登录时候通过 c.MustGet() 拿到用户名是什么,将用户名在“数据库”中做一个搜索,并将密码做一些匹配,如果成功,用户登录,返回正常 json
var secrets = gin.H{
"foo": gin.H{"email": "foo@bar.com", "phone": "123433"},
"austin": gin.H{"email": "austin@example.com", "phone": "666"},
"lena": gin.H{"email": "lena@guapa.com", "phone": "523443"},
}
func main() {
r := gin.Default()
authorized := r.Group("/admin", gin.BasicAuth(gin.Accounts{
"foo": "bar",
"austin": "1234",
"lena": "hello2",
"manu": "4321",
}))
authorized.GET("/secrets", func(c *gin.Context) {
user := c.MustGet(gin.AuthUserKey).(string)
if secret, ok := secrets[user]; ok {
c.JSON(http.StatusOK, gin.H{"user": user, "secret": secret})
} else {
c.JSON(http.StatusOK, gin.H{"user": user, "secret": "NO SECRET :("})
}
})
r.Run(":8080")
}
github.com/gin-contrib/sessions 包
虽然要引入 github.com/gin-contrib/sessions 包,但实际这个包也是属于 gin-gonic 组下的
r := gin.Default()
store := cookie.NewStore([]byte("secret"))
r.Use(sessions.Sessions("SESSIONID222", store))
等到登录成功,session set 值之后,接口返回的响应头中就会有 Set-Cookie 字段,其中内部的 key 就是 SESSIONID222,如下图所示
然后浏览器会保存 cookie 的内容,后面请求时候请求头中都会带上这个 cookie 如下
上面已经定义好使用这样的方式鉴权了,下面加入登录之后如何保存登录信息呢?如下在某个 HandlerFunc 中
username := c.PostForm("username")
password := c.PostForm("password")
if (username == "aaa" && password == "bbb") {
s := sessions.Default(c)
s.Set("user", username)
s.Save()
} else {
}
这样在一些页面中可以判定这个 s.Get(“user”) 的 session 是否存在来判定有没有登录
s := sessions.Default(c)
username := s.Get("user")
if username != nil {
} else {
}
总结核心思想:就是每次首次登录时候,请求方是没有带 cookie 的请求头的,这时候后端会判断用户密码是否符合数据库要求匹配之后,将用户信息存储到 session 中,然后该次请求响应头中返回 Set-Cookie 的字段,里头是 session 信息,然后后面的所有请求都会带上 Cookie 的请求头,里头的内容是刚才 session 的信息,这样后面每次请求都能判定 session 里头的信息在后端 session 中是否有被存储过,如果存储过即判定可以访问。如果后面退出登录,实际就是后端把 session 存储清空了,这样前端即使带着 Cookie 的请求头过来,后端 session 中依然找不到数据,因此判定为没有登录,因此无法访问
其实可以形象的理解成,首次登录时候相当于一个人没有身份证去向政府申请身份证,然后政府部门(后端)存储好了身份证数据,然后把这个身份证返给你个人(返给前端),然后你每次到政府各个部门办事就只用拿着一个身份证就能办事了,如果政府部门因为一些原因删除了你身份证的认定(退出登录,后端清除 session),那你即使带着身份证也无法在各个政府部门办事了,因此你需要重新找政府部门办理新的身份证(重新登录)
实际生产中使用鉴权方式
实际中主要用 JWT 鉴权或者是 oauth2 的包来做鉴权
JWT 非常常用,具体 gin 如何来结合 JWT 来鉴权使用,我会在另一篇博文专门讲解
|