binding · validation · middleware · CORS

go version go1.26.5 darwin/arm64
github.com/gin-gonic/gin v1.12.0
github.com/go-playground/validator/v10 v10.30.1
github.com/gin-contrib/cors v1.7.7

1 · จาก c.Param มาถึง body — ShouldBindJSON ทำอะไรให้บ้าง

บทที่แล้วเราอ่านค่าจาก URL ด้วย c.Param ซึ่งได้ string เสมอ แต่ POST /recipes ส่งข้อมูลมาเป็น JSON ใน body — ก้อนไบต์ที่ยังไม่มีรูปร่าง ถ้าทำมือเองต้องเขียนสามขั้น: อ่านสตรีมออกมา → json.Unmarshal → ไล่เช็คทีละ field ว่าครบไหม

var in Recipe
body, err := io.ReadAll(c.Request.Body)
if err != nil { /* 400 */ }
if err := json.Unmarshal(body, &in); err != nil {
    /* 400 */
}
if in.Title == "" { /* 400 */ }
if in.Servings < 1 { /* 400 */ }
// ...อีก 6 field

type Recipe struct {
    Title    string `json:"title" binding:"required"`
    Servings int    `json:"servings" binding:"min=1,max=20"`
}

var in Recipe
if err := c.ShouldBindJSON(&in); err != nil {
    c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
    return
}

ShouldBindJSON ทำสองงานรวดเดียว และสองงานนี้ล้มเหลวได้คนละแบบ ซึ่งเป็นเรื่องที่ต้องแยกให้ออกตั้งแต่ต้น:

ประเด็นที่ต้องจำจากตารางนี้: json กับ binding เป็นคนละ tag ทำคนละหน้าที่ · json:"title" บอกว่า "key ใน JSON ชื่อ title" (บทเรียน 13) ส่วน binding:"required" บอกว่า "ค่านี้ต้องผ่านกติกา" — ลบตัวหนึ่งทิ้ง อีกตัวยังทำงานอยู่

ผมรันให้ดูว่าสองแบบนี้ออกมาไม่เหมือนกันจริง (struct คือ ReqAge{ Age int `json:"age" binding:"required"` }):

// JSON พัง — ไม่ถึงขั้นตรวจกติกาเลย
===== 6 broken JSON syntax  POST /should  body={"name": =====
ERR_TYPE=*errors.errorString
ERR_STR=unexpected EOF

===== 6b wrong type  POST /should  body={"age":"abc"} =====
ERR_TYPE=*json.UnmarshalTypeError
ERR_STR=json: cannot unmarshal string into Go struct field ReqAge.age of type int

===== 6c empty body  POST /should =====
ERR_TYPE=*errors.errorString
ERR_STR=EOF

สังเกต EOF เฉย ๆ ในเคสสุดท้าย — นั่นคือ ผู้ใช้ยิงมาโดยไม่มี body เลย ถ้าคุณส่งข้อความนี้กลับไปตรง ๆ ฝั่ง frontend จะเห็นคำว่า EOF แล้วงงทั้งวัน (เดี๋ยวหัวข้อ 3 จะจัดการเรื่องนี้)

2 · หัวใจของบท — required ไม่ได้แปลว่า "ต้องส่งมา"

คำว่า required อ่านแล้วทุกคนแปลตรงกันว่า "ต้องมี field นี้ใน JSON"
ผิด — validator (ตัวตรวจกติกาที่ติดมากับ gin) ไม่รู้เลยว่า JSON เดิมมี key อะไรบ้าง มันเห็นแค่ struct หลัง unmarshal เสร็จแล้ว (unmarshal = ขั้นตอนแปลง JSON ให้กลายเป็น struct)
และมันตัดสินด้วยกฎเดียว: ค่านี้เป็น zero value ของชนิดตัวเองหรือเปล่า — zero value คือค่าที่ Go เติมให้เองเมื่อไม่มีใครกำหนดค่า: int เป็น 0 · string เป็น "" · bool เป็น false

ถ้าเป็น zero value → ไม่ผ่าน · จบ
ไม่สนว่ามันเป็นศูนย์เพราะ "ไม่ได้ส่งมา" หรือเพราะ "ส่งเลขศูนย์มาจริง ๆ" — สองอย่างนี้หน้าตาเหมือนกันเป๊ะในหน่วยความจำ

type ReqRecipe struct {
    Title     string `json:"title" binding:"required"`
    Servings  int    `json:"servings" binding:"required"`
    Published bool   `json:"published" binding:"required"`
}

POST /plain body={"title":"ผัดกะเพรา","servings":2,"published":true}
  -> STATUS=200 BODY={"title":"ผัดกะเพรา","servings":2,"published":true}
POST /plain body={"title":"","servings":2,"published":true}
  -> STATUS=400 BODY={"error":"Key: 'ReqRecipe.Title' Error:Field validation for 'Title' failed on the 'required' tag"}
POST /plain body={"title":"ผัดกะเพรา","servings":0,"published":true}
  -> STATUS=400 BODY={"error":"Key: 'ReqRecipe.Servings' Error:Field validation for 'Servings' failed on the 'required' tag"}
POST /plain body={"title":"ผัดกะเพรา","servings":2,"published":false}
  -> STATUS=400 BODY={"error":"Key: 'ReqRecipe.Published' Error:Field validation for 'Published' failed on the 'required' tag"}

แล้วมันแยกไม่ออกจริงหรือ? จริง — ผมยิง {"age":0} กับ {} เข้า struct เดียวกัน ได้ error ตัวเดียวกันเป๊ะทุกตัวอักษร:

===== 2 required + zero value  POST /should  body={"age":0} =====
ERR_STR=Key: 'ReqAge.Age' Error:Field validation for 'Age' failed on the 'required' tag

===== 2b required + missing field  POST /should  body={} =====
ERR_STR=Key: 'ReqAge.Age' Error:Field validation for 'Age' failed on the 'required' tag

ทางแก้: pointer

*int มี zero value เป็น nil ไม่ใช่ 0 — และ nil เกิดขึ้นได้ทางเดียวคือ JSON ไม่มี key นั้นเลย (บทเรียน 7)
พอ key มีอยู่จริง encoding/json จะจองที่ให้ค่าแล้วชี้ไปหา แม้ค่านั้นจะเป็น 0 ก็ตาม → pointer ไม่ nil → required ผ่าน

body ที่ส่งมา            Servings int          Servings *int
─────────────────────    ─────────────────     ────────────────────
{"servings": 2}          2    ✅ ผ่าน           &2   ✅ ผ่าน
{"servings": 0}          0    ❌ ไม่ผ่าน  ←     &0   ✅ ผ่าน  ← จุดที่ต่างกัน
{}  (ไม่ส่งมาเลย)         0    ❌ ไม่ผ่าน         nil  ❌ ไม่ผ่าน
                         └─ สองแถวล่างแยกไม่ออก   └─ แยกออก

รันจริงด้วย struct ชุดเดิมแต่เปลี่ยนเป็น pointer ทั้งสามช่อง:

type ReqRecipePtr struct {
    Title     *string `json:"title" binding:"required"`
    Servings  *int    `json:"servings" binding:"required"`
    Published *bool   `json:"published" binding:"required"`
}

POST /ptr body={"title":"ผัดกะเพรา","servings":0,"published":false}
  -> STATUS=200 BODY={"published":false,"servings":0,"title":"ผัดกะเพรา"}

POST /ptr body={"servings":0,"published":false}          # ไม่มี title เลย
  -> STATUS=400 BODY={"error":"Key: 'ReqRecipePtr.Title' Error:Field validation for 'Title' failed on the 'required' tag"}

3 · tag ที่ใช้จริง และ error ที่ห้ามส่งให้ผู้ใช้ตรง ๆ

required เป็นแค่ตัวเดียวใน tag หลายสิบตัวของ validator/v10 สามตัวที่เจอบ่อยที่สุดในงาน API จริงคือ email · min/max · oneof

type ReqEmail struct {
    Email string `json:"email" binding:"required,email"`
}

type ReqRange struct {
    Level      int    `json:"level" binding:"min=1,max=5"`
    Difficulty string `json:"difficulty" binding:"oneof=easy medium hard"`
}

หลาย tag ต่อกันด้วย comma และตรวจตามลำดับซ้ายไปขวา — ตัวแรกที่ตกคือตัวที่รายงาน ผมรันเทียบสองเคสให้ดู:

===== 4 email invalid  POST /email  body={"email":"not-an-email"} =====
ERR_STR=Key: 'ReqEmail.Email' Error:Field validation for 'Email' failed on the 'email' tag

===== 4b email empty  POST /email  body={} =====
ERR_STR=Key: 'ReqEmail.Email' Error:Field validation for 'Email' failed on the 'required' tag

ค่าว่างติด required ก่อน ไม่เดินไปถึง email — นี่คือเหตุผลที่ควรเขียน required ไว้หน้าสุดเสมอ ไม่งั้นข้อความ error จะบอกว่า "รูปแบบอีเมลผิด" ทั้งที่ผู้ใช้แค่ยังไม่ได้กรอก

และเมื่อผิดหลาย field พร้อมกัน validator รายงานทุกตัว ต่อกันด้วย \n ในสตริงเดียว:

===== 5 min/max + oneof  POST /range  body={"level":9,"difficulty":"insane"} =====
ERR_STR=Key: 'ReqRange.Level' Error:Field validation for 'Level' failed on the 'max' tag
Key: 'ReqRange.Difficulty' Error:Field validation for 'Difficulty' failed on the 'oneof' tag
STATUS=400
BODY={"error":"Key: 'ReqRange.Level' Error:Field validation for 'Level' failed on the 'max' tag\nKey: 'ReqRange.Difficulty' Error:Field validation for 'Difficulty' failed on the 'oneof' tag"}

ทางออกคือ อย่าโยน err.Error() ออกไปตรง ๆ ใน production ให้แปลงเป็นข้อความของเราเองก่อน · validator.ValidationErrors เป็น slice (รายการที่เก็บของหลายชิ้นเรียงกัน) จึงวนอ่านทีละตัวได้ และแยกออกจาก parse error ได้ด้วย errors.As (บทเรียน 12)
โค้ดข้างล่างต้อง import สองตัวเพิ่ม: errors ของ Go เอง และ github.com/go-playground/validator/v10 (ตัวที่ติดมากับ gin อยู่แล้ว ไม่ต้อง go get):

var ve validator.ValidationErrors
if errors.As(err, &ve) {
    out := make(map[string]string, len(ve))
    for _, fe := range ve {
        out[fe.Field()] = fe.Tag()   // "Difficulty" -> "oneof"
    }
    c.JSON(http.StatusBadRequest, gin.H{"fields": out})
    return
}
// มาถึงตรงนี้ = JSON เองพัง ไม่ใช่ค่าไม่ผ่านกติกา
c.JSON(http.StatusBadRequest, gin.H{"error": "invalid JSON body"})

ผมรันโค้ดชุดนี้กับ ReqRange จริง ๆ สี่เคส ได้ response ที่ผู้ใช้อ่านรู้เรื่องแล้ว:

body={"level":9,"difficulty":"insane"} -> 400 {"fields":{"Difficulty":"oneof","Level":"max"}}
body={"level":0,"difficulty":"easy"}   -> 400 {"fields":{"Level":"min"}}
body={"level":3,"difficulty":"hard"}   -> 200 {"ok":true}
body={"title":                         -> 400 {"error":"invalid JSON body"}   ← ไปทางอื่น

สังเกตบรรทัดสุดท้าย: JSON ที่พังตกไปคนละทางกับค่าที่ไม่ผ่านกติกาแล้ว
สังเกตบรรทัดที่สอง: level=0 ติด 'min' ไม่ใช่ 'required' — เพราะชุดนี้ผมไม่ได้ใส่ required ไว้ · min=1 ทำหน้าที่กันศูนย์ให้อยู่แล้ว ซึ่งเป็นทางเลือกที่ตรงกว่า required เมื่อสิ่งที่คุณหมายถึงจริง ๆ คือ "ต้องมากกว่าศูนย์"

4 · ShouldBind* vs Bind* — และ query/uri ใช้ tag คนละตัว

Gin มีเมธอด bind สองตระกูลที่ทำงานเหมือนกันเป๊ะ ต่างกันแค่ตอนที่มัน error:
ShouldBindJSON คืน error แล้วไม่แตะ response เลย — เราตัดสินใจเองทั้งหมด
BindJSON คืน error แล้วเขียน 400 ให้เสร็จสรรพ พร้อม c.Abort() ให้ด้วย

ฟังดูเหมือน BindJSON สะดวกกว่า จนกระทั่งเราเขียน response ต่อจากมัน
handler ที่ผมใช้ทดสอบหน้าตาแบบนี้ — นี่คือเคส 1c · เคส 1b ต่างแค่เปลี่ยน 422 เป็น 400 · เคส 1d คือลบทั้งก้อน if ทิ้ง เรียก BindJSON แล้วจบเลยไม่เขียนอะไรต่อ:

r.POST("/bind422", func(c *gin.Context) {
    if err := c.BindJSON(&ReqAge{}); err != nil {
        c.JSON(http.StatusUnprocessableEntity, gin.H{"error": err.Error()})
        return
    }
    c.JSON(http.StatusOK, gin.H{"ok": true})
})

ยิง {"age":0} เข้าไปทั้งสามเคส — ReqAge ใส่ required ไว้ ค่า 0 จึงไม่ผ่านตามหัวข้อ 2 · ในผลรัน WrittenBefore คือค่าจาก c.Writer.Written() ที่แปลว่า "มีคนเขียน response ลงสายไปแล้วหรือยัง":

===== 1b BindJSON + c.JSON(400)  body={"age":0} =====
IsAborted=true WrittenBefore=true Status=400
STATUS=400
BODY="{\"error\":\"Key: 'ReqAge.Age' Error:Field validation for 'Age' failed on the 'required' tag\"}"

===== 1c BindJSON + c.JSON(422)  body={"age":0} =====
[GIN-debug] [WARNING] Headers were already written. Wanted to override status code 400 with 422
STATUS=400
BODY="{\"error\":\"Key: 'ReqAge.Age' Error:Field validation for 'Age' failed on the 'required' tag\"}"

===== 1d BindJSON only, handler returns  body={"age":0} =====
STATUS=400
CTYPE=""
BODY=""

เคส 1b ดูปกติดี — แต่ปกติเพราะบังเอิญเราขอ 400 ซึ่งตรงกับที่ gin เขียนไปแล้วพอดี
เคส 1c คือของจริง: ขอ 422 แต่ได้ 400 เพราะ HTTP status เขียนลงสายได้ครั้งเดียว พอ BindJSON เขียนไปแล้ว ใครมาทีหลังก็เปลี่ยนไม่ได้ ได้แค่ warning ปลอบใจ
เคส 1d คือสิ่งที่เกิดถ้าเราคิดว่า "gin จัดการให้แล้ว ไม่ต้องเขียนอะไรต่อ" — ผู้ใช้ได้ 400 กับ body ว่างเปล่า ไม่มีคำอธิบายสักตัว

== release mode: BindJSON + c.JSON(422) ==
STATUS=400 BODY="{\"error\":\"Key: 'ReqAge.Age' Error:Field validation for 'Age' failed on the 'required' tag\"}"

ทำไมถึงเป็นแบบนั้น? BindJSON เป็นแค่เปลือกบาง ๆ ที่ส่งต่อให้ MustBindWith ทำงานจริง ซึ่งข้างในเป็นแบบนี้ (จาก context.go ของ gin v1.12.0):

func (c *Context) MustBindWith(obj any, b binding.Binding) error {
    err := c.ShouldBindWith(obj, b)
    if err != nil {
        // ...
        c.AbortWithError(http.StatusBadRequest, err).SetType(ErrorTypeBind)
        return err
    }
    return nil
}

บรรทัดที่ทำให้เกิดเรื่องทั้งหมดคือ c.AbortWithError(http.StatusBadRequest, err) — มันเขียน status 400 ลงสายไปเรียบร้อยตั้งแต่ตอนนั้น (คำว่า Abort แปลว่าอะไรกันแน่ ค่อยเจาะในหัวข้อ 6)

bind จาก query กับ URI — tag เปลี่ยนไปอีก

ข้อมูลไม่ได้มาแค่ทาง body · GET /recipes?q=go&page=2 ส่งมาทาง query string และ GET /recipes/42 ส่งมาทาง path · gin แยกเมธอดให้คนละตัว และดู tag คนละชื่อ ซึ่งเป็นจุดที่คนใหม่เสียเวลามากที่สุด

ที่หลอกคือ "field ไม่ถูกเติม" ไม่ใช่ compile error และไม่ใช่ error ตอนรันด้วย — มันแค่เงียบ ๆ ปล่อยให้ค่าเป็น zero value แล้วไปตกที่ required ทีหลัง ทำให้ข้อความ error ชี้ไปผิดที่:

===== 7 ShouldBindQuery form tag  GET /query?q=go&page=2 =====
STATUS=200
BODY="{\"page\":2,\"q\":\"go\"}"

===== 7c ShouldBindQuery with json tag only  GET /queryjsontag?q=go =====
ERR_STR=Key: 'ReqQueryJSONTag.Q' Error:Field validation for 'Q' failed on the 'required' tag
STATUS=400

===== 7d ShouldBindUri uri tag  GET /uri/42/hello =====
STATUS=200
BODY="{\"id\":\"42\",\"slug\":\"hello\"}"

===== 7e ShouldBindUri with form tag only  GET /urifromtag/42 =====
ERR_STR=Key: 'ReqUriFormTag.ID' Error:Field validation for 'ID' failed on the 'required' tag
STATUS=400

เคส 7c คือ ?q=go ที่ส่งมาถูกต้องทุกอย่าง แต่ server บอกว่า "ไม่ได้ส่ง q มา" เพราะ struct เขียน json:"q" แทน form:"q" — debug ตรงนี้ยากมากถ้าไม่รู้ว่ามันมี tag คนละตัว

5 · middleware — handler ที่ต่อคิว และ c.Next() คือการปล่อยคิวเดินต่อ

ทุก API มีงานที่ต้องทำกับทุก request: บันทึก log · เช็ค token · จับเวลา · ใส่ request ID ถ้าก๊อปโค้ดพวกนี้ไปวางในทุก handler ก็จะลืมสักตัวแน่นอน — middleware คือที่ที่งานพวกนี้ควรอยู่

หน้าตาของ middleware ไม่ต่างจาก handler เลยแม้แต่นิดเดียว: มันคือ func(c *gin.Context) ตัวหนึ่ง · สิ่งเดียวที่ทำให้มันเป็น "middleware" คือมันถูก ลงทะเบียนด้วย r.Use() ให้อยู่ในคิวก่อน handler จริง

gin เก็บทุกอย่างที่ต้องรันสำหรับ route หนึ่งไว้เป็นคิวเดียว (slice ของฟังก์ชัน) แล้วเดินทีละตัว · c.Next() แปลว่า "หยุดฉันไว้ตรงนี้ ไปรันตัวถัดไปในคิวจนจบก่อน แล้วค่อยกลับมาทำบรรทัดถัดไปของฉัน"
ผลคือโค้ดเหนือ c.Next() รันขาไป และโค้ดใต้ c.Next() รันขากลับ — ซึ่งเป็นเหตุผลว่าทำไม middleware ถึงจับเวลาทั้ง request ได้

func A(c *gin.Context) {
    fmt.Println("A: before Next")
    c.Next()
    fmt.Println("A: after Next")
}
func B(c *gin.Context) {
    fmt.Println("B: before Next")
    c.Next()
    fmt.Println("B: after Next")
}

r.Use(A)
r.Use(B)
r.GET("/ping", func(c *gin.Context) {
    fmt.Println("HANDLER: /ping")
    c.String(200, "pong")
})

$ go run ./order
A: before Next
B: before Next
HANDLER: /ping
B: after Next
A: after Next
--- status: 200 body: pong

            ขาไป (บรรทัดเหนือ c.Next)          ขากลับ (บรรทัดใต้ c.Next)
request ──▶ ┌──────────── A ────────────────────────────────────┐ ──▶ response
            │ "A: before"                          "A: after"   │
            │  ┌───────── B ─────────────────────────────────┐  │
            │  │ "B: before"                     "B: after"  │  │
            │  │   ┌────── handler ──────────────────────┐   │  │
            │  │   │        "HANDLER: /ping"             │   │  │
            │  │   └─────────────────────────────────────┘   │  │
            │  └─────────────────────────────────────────────┘  │
            └───────────────────────────────────────────────────┘
              ลำดับจริง:  A before → B before → HANDLER → B after → A after

รูปหัวหอมนี้อธิบายทุกอย่างที่ middleware ทำได้ในประโยคเดียว: ขาไปคือ "ก่อนรู้คำตอบ" ขากลับคือ "หลังรู้คำตอบแล้ว"
เช็ค token ต้องอยู่ขาไป (ต้องกันไว้ก่อน) · จับเวลาและ log status ต้องคร่อมทั้งสองขา:

func Timing() gin.HandlerFunc {
    return func(c *gin.Context) {
        start := time.Now()          // ขาไป: ยังไม่รู้ว่า handler จะตอบอะไร
        c.Next()
        // ขากลับ: ตรงนี้ handler ทำงานจบแล้ว จึงอ่าน status ได้
        log.Printf("%s %s -> %d in %v",
            c.Request.Method, c.Request.URL.Path,
            c.Writer.Status(), time.Since(start))
    }
}

6 · c.Abort() — จุดที่คนใหม่พลาดเยอะที่สุด

middleware ที่กันคนแปลกหน้าต้องทำสองอย่าง: ตอบว่าทำไมไม่ให้ผ่าน และ สั่งหยุดคิว · ถ้าทำอย่างเดียวจะพังคนละแบบ และทั้งสองแบบเงียบมาก

ผมรันครบสี่เคสด้วยคิว A (ชั้นนอก) → B (ชั้นใน) → handler · A คือตัวที่พิมพ์ before Next / after Next คร่อมไว้เฉย ๆ ส่วน B คือตัวที่ทำหน้าที่ปฏิเสธ ซึ่งเปลี่ยนไปทีละเคส
(ในเคส 3 ไม่มีบรรทัด B: ขึ้นมาเพราะโค้ดของ B เคสนั้นมีแค่ c.AbortWithStatus(401) บรรทัดเดียว ไม่ได้สั่งพิมพ์อะไร — ไม่ใช่ว่า B ไม่ทำงาน):

========= CASE 1: c.Abort() alone, no response written =========
A : before Next
B: aborting with plain c.Abort()
A : after Next  (IsAborted = true )
--- status=200 contentType="" bodyLen=0 body=""

========= CASE 2: c.AbortWithStatusJSON(401, ...) =========
A : before Next
B: AbortWithStatusJSON(401)
A : after Next  (IsAborted = true )
--- status=401 contentType="application/json; charset=utf-8" bodyLen=24 body="{\"error\":\"unauthorized\"}"

========= CASE 3: c.AbortWithStatus(401) (no body) =========
A : before Next
A : after Next  (IsAborted = true )
--- status=401 contentType="" bodyLen=0 body=""

========= CASE 4: c.JSON(401) WITHOUT Abort (classic bug) =========
A : before Next
B: c.JSON(401) but forgot Abort
HANDLER RAN  <-- yes, it does
A : after Next  (IsAborted = false )
--- status=401 contentType="application/json; charset=utf-8" bodyLen=26 body="{\"error\":\"unauthorized\"}ok"

ยืนยันอีกชั้นด้วยการเปิด server จริงบนพอร์ตหนึ่ง แล้วยิงด้วย curl ผ่านเน็ตเวิร์กจริง — ไม่ใช่แค่ httptest ที่เรียกกันอยู่ในโปรแกรมเดียวกัน (curl -i คือสั่งให้พิมพ์ header ของ response ออกมาด้วย):

$ curl -s -i http://127.0.0.1:39181/abort-only
HTTP/1.1 200 OK
Date: Thu, 20 Aug 2026 14:49:43 GMT
Content-Length: 0

$ curl -s -i http://127.0.0.1:39181/abort-json
HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Date: Thu, 20 Aug 2026 14:49:43 GMT
Content-Length: 24

{"error":"unauthorized"}

อีกจุดที่ต้องรู้: Abort() หยุดเฉพาะสิ่งที่ยังไม่ได้รัน ส่วนโค้ดใต้ c.Next() ของ middleware ชั้นนอกยังทำงานเสมอ (ในผลรันข้างบน A : after Next ขึ้นทุกเคส) — เพราะ A ค้างรออยู่ตรงนั้นอยู่แล้ว
นี่คือเหตุผลที่ logger middleware ยังบันทึก request ที่โดน auth ปฏิเสธได้ครบ และเป็นเหตุผลที่โค้ดขากลับควรเช็ค c.IsAborted() ก่อนทำงานหนัก

ส่งของจาก middleware ไปให้ handler: c.Set / c.Get

middleware ที่ตรวจ token แล้วรู้ว่าเป็นใคร ต้องส่งข้อมูลนั้นต่อให้ handler · ช่องทางคือ c.Set(key, value) แล้วอีกฝั่ง c.Get(key) ซึ่งเก็บเป็น any จึงต้อง type-assert เอง (บทเรียน 11)

$ go run ./ctxdata
=== GET /ok ===
Get("user")     -> value=main.User{Name:"bingza"} exists=true
Get("nope")     -> value=<nil> exists=false
MustGet("user") -> main.User{Name:"bingza"}
MustGet("user").(string) comma-ok -> "" ok=false

=== GET /panic ===
RECOVERED panic type=string value=key missing-key does not exist

c.Get คืน (any, bool) — ไม่เจอก็แค่ nil, false
c.MustGet ถ้าไม่มี key จะ panic ด้วยข้อความ key missing-key does not exist (missing-key คือชื่อ key ที่เราเรียกหาในการรันนั้น ไม่ใช่คำคงที่ของ gin) · ถ้ามี gin.Recovery() อยู่ (ซึ่ง gin.Default() ใส่ให้) panic นี้จะกลายเป็น 500 body ว่าง
ใช้ MustGet ได้เมื่อคุณแน่ใจว่า middleware ที่ Set ค่านั้นถูกผูกไว้กับ route นี้แน่นอน — ซึ่งพาไปสู่เรื่องถัดไปพอดี

middleware ผูกกับ group ไม่ใช่ผูกกับเวลา

r.Group จาก บทเรียน 38 ไม่ได้ใช้แค่ตัด prefix ซ้ำ ๆ — มันมี Use() เป็นของตัวเอง ทำให้ผูก middleware เข้ากับเฉพาะ route ในกลุ่มนั้นได้
โค้ดที่ผมรันเป็นแบบนี้:

r := gin.New()
r.GET("/public", /* ... */)

admin := r.Group("/admin")
admin.Use(func(c *gin.Context) {          // ผูกกับ group นี้ตัวเดียว
    fmt.Println("  [authMW] ran for", c.Request.URL.Path)
    if c.GetHeader("X-Token") != "secret" {
        c.AbortWithStatusJSON(401, gin.H{"error": "no token"})
        return
    }
    c.Next()
})
admin.GET("/stats", /* ... */)

r.GET("/other", /* ... */)     // เขียนทีหลัง admin.Use แต่คนละ group

$ go run ./group
=== GET /public (X-Token="") ===
  -> status=200 body="public ok"

=== GET /other (X-Token="") ===
  -> status=200 body="other ok"

=== GET /admin/stats (X-Token="") ===
  [authMW] ran for /admin/stats
  -> status=401 body="{\"error\":\"no token\"}"

=== GET /admin/stats (X-Token="secret") ===
  [authMW] ran for /admin/stats
  -> status=200 body="admin stats"

[authMW] ran ขึ้นเฉพาะใน /admin/* เท่านั้น — /other ที่ลงทะเบียนหลัง admin.Use(...) ก็ไม่โดน เพราะมันอยู่คนละ group
แต่ในกลุ่มเดียวกัน ลำดับบรรทัดมีผลเต็ม ๆ:

=== group.Use AFTER route registered in same group ===
  GET /g/early -> status=200 body="early"          # ไม่มี [g mw] ขึ้นเลย
  [g mw] ran for /g/late
  GET /g/late  -> status=200 body="late"

/g/early ลงทะเบียนก่อน g.Use(...) จึงไม่ได้ middleware ติดไปด้วย
เหตุผลคือ gin ก๊อปคิว ณ วินาทีที่ลงทะเบียน route ไม่ใช่ตอนมี request เข้ามา — Use() ที่มาทีหลังจึงย้อนไปแก้ route เก่าไม่ได้ · จำสั้น ๆ ว่า Use() ต้องมาก่อน GET/POST เสมอ ซึ่งจะกลับมาหลอกเราอีกครั้งในหัวข้อถัดไป

7 · CORS — กฎของเบราว์เซอร์ ไม่ใช่ยามหน้าประตูของ server

อาการคลาสสิกที่ทุกคนต้องเจอ: Postman ยิงผ่าน · curl ผ่าน · แต่เว็บของตัวเองเรียกไม่ได้ ขึ้น error สีแดงว่าโดน CORS บล็อก
สาเหตุคือ CORS ไม่ได้ทำงานที่ server เลย · มันเป็นกฎที่ เบราว์เซอร์ บังคับใช้กับโค้ด JavaScript ที่มันรันอยู่

คำที่ต้องรู้ก่อนหนึ่งคำ: origin = โปรโตคอล + โดเมน + พอร์ต รวมกันสามอย่าง · https://app.example.com กับ http://app.example.com คนละ origin (โปรโตคอลต่าง) และ https://api.example.com ก็คนละ origin (โดเมนต่าง)

กฎเดิมของเว็บชื่อ same-origin policy: JS ที่โหลดมาจาก https://app.example.com อ่านคำตอบจาก origin อื่นไม่ได้ ไม่งั้นเว็บร้ายเปิดค้างไว้ จะแอบยิงไปที่ธนาคารของคุณ (ซึ่งมี cookie ติดไปด้วย) แล้วอ่านยอดเงินได้เลย
CORS คือช่องทางที่ server ใช้บอกเบราว์เซอร์ว่า "ฉันอนุญาตเว็บนี้" ผ่าน response header (บรรทัดข้อมูลกำกับที่แนบไปกับคำตอบ คนละส่วนกับ body) · เบราว์เซอร์เป็นคนอ่าน header นั้นแล้วตัดสินใจ — ไม่ใช่ server

preflight — request ที่เบราว์เซอร์ยิงเองโดยที่เราไม่ได้สั่ง

สำหรับ request ที่ "ไม่ธรรมดา" (มี Content-Type: application/json, มี header Authorization, หรือใช้ method อย่าง PUT/DELETE) เบราว์เซอร์จะยิง OPTIONS ไปถามก่อนว่าอนุญาตไหม แล้วค่อยยิงของจริง
แปลว่า API ของคุณต้องตอบ OPTIONS ให้เป็น — ซึ่งเป็นงานของ cors middleware:

$ curl -s -i -X OPTIONS -H "Origin: https://evil.example.com" \
    -H "Access-Control-Request-Method: POST" http://127.0.0.1:39182/data
HTTP/1.1 204 No Content
Access-Control-Allow-Headers: Origin,Content-Length,Content-Type
Access-Control-Allow-Methods: GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 43200
Date: Thu, 20 Aug 2026 14:50:43 GMT

เซิร์ฟเวอร์ตัวนี้ใช้แค่ a.Use(cors.Default()) บรรทัดเดียว สังเกตสามอย่าง:
1. status เป็น 204 No Content ไม่ใช่ 200
2. เราไม่ต้องลงทะเบียน route OPTIONS เอง — cors middleware ตอบแล้ว Abort จบให้เลย
3. Max-Age: 43200 คือ 12 ชั่วโมง (หน่วยวินาที) แปลว่าเบราว์เซอร์จำคำตอบนี้ไว้ ไม่ต้องยิง OPTIONS ถามซ้ำทุก request

ส่วน request จริง (ไม่ใช่ preflight) ได้ header น้อยกว่ามาก — แค่ตัวเดียว:

$ curl -s -i -H "Origin: https://evil.example.com" http://127.0.0.1:39182/data
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Content-Length: 11

{"ok":true}

# ยิงโดยไม่ส่ง Origin มาเลย
$ curl -s -i http://127.0.0.1:39182/data
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 11

{"ok":true}          ← ไม่มี CORS header สักตัว

สองกับดักของ cors.Default() และ cors.New()

cors.Default() อนุญาตทุก origin (*) ซึ่งพอสำหรับตอนพัฒนา แต่มีรูที่ทำให้ระบบที่มี login ใช้ไม่ได้ ผมลองขอ Authorization ตอน preflight:

$ curl -s -i -X OPTIONS -H "Origin: https://evil.example.com" \
    -H "Access-Control-Request-Method: POST" \
    -H "Access-Control-Request-Headers: Content-Type, Authorization" http://127.0.0.1:39182/data
HTTP/1.1 204 No Content
Access-Control-Allow-Headers: Origin,Content-Length,Content-Type
Access-Control-Allow-Methods: GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 43200

ตอบ 204 เหมือนเดิม แต่ในลิสต์ ไม่มีคำว่า Authorization — เว็บที่ส่ง JWT (รูปแบบ token ที่ใช้บอกว่าคนยิงเข้ามาเป็นใคร) ผ่าน Authorization: Bearer ... จะโดนเบราว์เซอร์บล็อก ทั้งที่ server ตอบ 204 สวยงาม

ทีนี้พอเปลี่ยนไปใช้ cors.New() เพื่อระบุ origin เจาะจง ก็เจอกับดักที่สอง — cors.New() ไม่ merge ค่า default ให้ ใส่อะไรได้อย่างนั้น:

cors.New(cors.Config{
    AllowOrigins: []string{"https://app.example.com"},
})

$ curl -X OPTIONS -H "Origin: https://app.example.com" \
    -H "Access-Control-Request-Method: POST" ...
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Vary: Origin
← ไม่มี Allow-Methods / Allow-Headers เลย

r.Use(cors.New(cors.Config{
    AllowOrigins:     []string{"https://app.example.com"},
    AllowMethods:     []string{"GET", "POST", "PUT", "DELETE", "OPTIONS"},
    AllowHeaders:     []string{"Origin", "Content-Type", "Authorization"},
    ExposeHeaders:    []string{"Content-Length"},
    AllowCredentials: true,
    MaxAge:           12 * time.Hour,
}))

HTTP/1.1 204 No Content
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Origin,Content-Type,Authorization
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Max-Age: 43200

ข้อดีของ gin-contrib/cors คือมันตัดจบที่ 403 เลยเมื่อ origin ไม่อยู่ในลิสต์ ไม่ใช่ตอบ 200 แล้วไม่ใส่ header แบบ lib บางตัว — ทำให้ debug ง่ายกว่ามาก:

$ curl -s -i -H "Origin: https://evil.example.com" http://127.0.0.1:39183/data
HTTP/1.1 403 Forbidden
Date: Thu, 20 Aug 2026 14:50:48 GMT
Content-Length: 0

c := gin.New()
c.GET("/before", func(ctx *gin.Context) {
    ctx.JSON(200, gin.H{"which": "before"})
})
c.Use(cors.Default())          // <-- มาทีหลัง
c.GET("/after", func(ctx *gin.Context) {
    ctx.JSON(200, gin.H{"which": "after"})
})

$ curl -s -i -X OPTIONS -H "Origin: https://x.example.com" \
    -H "Access-Control-Request-Method: POST" http://127.0.0.1:39184/before
HTTP/1.1 204 No Content
Access-Control-Allow-Headers: Origin,Content-Length,Content-Type
Access-Control-Allow-Methods: GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 43200

$ curl -s -i -H "Origin: https://x.example.com" http://127.0.0.1:39184/before
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 18

{"which":"before"}          ← ไม่มี CORS header

$ curl -s -i -H "Origin: https://x.example.com" http://127.0.0.1:39184/after
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8

{"which":"after"}

$ curl -s -i -H "Origin: https://x.example.com" http://127.0.0.1:39184/totally-unknown
HTTP/1.1 404 Not Found
Access-Control-Allow-Origin: *
Content-Type: text/plain

404 page not found

8 · กับดักทั้งบทในตารางเดียว

ทดสอบความเข้าใจ

A: before Next
B: before Next
HANDLER: /ping
B: after Next
A: after Next

อ้างอิง

• Gin — Model binding and validation — ต้นทางของ ShouldBindJSON และตาราง Should* vs Must*
• pkg.go.dev — validator/v10 — อ่านหัวข้อ Baked-in Validations: รายชื่อ tag ทั้งหมด และนิยามของ required ที่ว่า "ไม่เป็น zero value ของชนิดนั้น"
• Gin — Bind Uri · Bind body into different structs — ที่มาของ tag uri และ ShouldBindBodyWith
• Gin — Using middleware · Custom middleware — r.Use, c.Next, c.Set
• pkg.go.dev — gin.Context — เอกสารของ Next / Abort / AbortWithStatusJSON / MustGet
• github.com/gin-contrib/cors · pkg.go.dev — ค่า default ของ cors.Default() และทุกช่องใน cors.Config
• MDN — Cross-Origin Resource Sharing — อ่านหัวข้อ Preflight requests: เงื่อนไขว่า request แบบไหนถึงจะโดน OPTIONS ก่อน
• Cheat sheet Day 8 — tag ที่ใช้บ่อยและตารางกับดักรวมทั้งวัน