chain ที่วางผิดลำดับ แล้วแอปไม่ยอมสตาร์ต

สามบทที่ผ่านมามี SecurityFilterChain ตัวเดียว กฎทุกข้อจึงอยู่ในที่เดียวกัน · ระบบจริงมักไม่เป็นแบบนั้น · API กับหน้าเว็บมักต้องการกฎคนละชุด

บทนี้ประกาศสองตัว แล้ววัดว่าเกิดอะไรขึ้น

สองตัว หนึ่งกว้าง หนึ่งแคบ

ตัวที่ไม่ประกาศขอบเขต ครอบทุกคำขอโดยปริยาย

@Bean
@Order(1)
fun wide(http: HttpSecurity): SecurityFilterChain {
    http.authorizeHttpRequests { it.anyRequest().hasRole("ADMIN") }
    http.httpBasic { }
    return http.build()
}

@Bean
@Order(2)
fun narrow(http: HttpSecurity): SecurityFilterChain {
    http.securityMatcher("/open")
    http.authorizeHttpRequests { it.anyRequest().permitAll() }
    return http.build()
}

securityMatcher คือสิ่งที่บอกว่า chain ตัวหนึ่งครอบคำขอแบบไหน · ตัวที่ไม่ประกาศ ครอบทุกอย่าง

@Order ของ chain คือลำดับที่ระบบไล่หาตัวที่ตรง · เลขน้อยมาก่อน

ผมคาดว่ากฎจะเงียบหาย แต่แอปสร้าง bean ไม่สำเร็จเลย

ผมเดาผิด และการเดาผิดนี้เป็นเนื้อหาของบท

ตอนวางแผนคอร์ส ผมเขียนไว้ว่าคำขอไปที่ /open จะถูก chain กว้างรับไปก่อน แล้วได้ 401 ส่วนกฎ permitAll ในตัวแคบจะไม่มีใครได้ใช้ · เงียบๆ แบบนั้น

การวัดตอบว่า แอปสร้าง bean ไม่สำเร็จเลย

org.springframework.security.web.UnreachableFilterChainException

ไม่มีคำขอไหนถูกยิงเลย เพราะไม่มีเซิร์ฟเวอร์ให้ยิง

ความผิดพลาดที่ย้ายจากเงียบมาเป็นดัง

ในรุ่นก่อนหน้า การวางลำดับแบบนี้เป็นความผิดพลาดที่ทำงานได้ · แอปขึ้น คำขอวิ่ง และกฎที่คุณเขียนไว้อย่างตั้งใจก็ไม่เคยถูกใช้

ตอนนี้มันเป็นความผิดพลาดที่หยุดคุณตั้งแต่ต้น · นี่คือการเปลี่ยนแปลงที่ดี ต่อให้มันทำให้คุณเสียเวลาตอนอัปเกรด

สลับลำดับ แล้ววัดใหม่

เปลี่ยนแค่สองเลข ไม่แตะอย่างอื่น

ให้ตัวแคบเป็น @Order(1) และตัวกว้างเป็น @Order(2) · แอปสตาร์ตได้

ทรง	`GET /open`	chain ที่รับ
กว้างก่อน	แอปสตาร์ตไม่ขึ้น	—
แคบก่อน	`200`	`narrow`

รหัส 200 อย่างเดียวพิสูจน์ไม่ได้ว่า chain ไหนเป็นคนรับ เพราะทั้งสองตัว อาจให้ 200 ได้ด้วยเหตุผลคนละอย่าง · ป้ายในช่องขวาจึงมาจาก filter ที่เราแทรก เข้าไปในแต่ละ chain เพื่อเขียน header บอกชื่อตัวเอง

กฎที่เหลือจากบทนี้

เรียงจากแคบไปกว้าง และให้ตัวที่ครอบทุกอย่างอยู่ท้ายสุดเสมอ

chain ที่ไม่ประกาศ securityMatcher ต้องเป็นตัวสุดท้าย
chain ที่ประกาศไว้ ต้องเรียงจากขอบเขตแคบไปกว้าง
อย่าเชื่อรหัสตอบกลับเพื่อพิสูจน์ว่า chain ไหนทำงาน ให้ใส่ป้ายแล้ววัดป้าย

สิ่งที่บทนี้ทิ้งไว้

จัดโครงเป็นแล้ว แต่ body ของคำตอบที่ปฏิเสธยังว่างเปล่าเหมือนบทที่ 1

ตั้งแต่บทแรกจนถึงบทนี้ ผู้เรียกที่ถูกปฏิเสธยังได้แต่ตัวเลข · บทถัดไปเอา body กลับเข้าสัญญาเดิม และวัดว่าต้องลงมือกี่ที่

ที่มาของตัวเลขในบทนี้

Spring Boot 4.1.1 · Spring Security 7.1.1 · Kotlin 2.4.10 · JDK 25
รันซ้ำเองได้ด้วย npm run verify:clinic-security · ต้องสั่ง scripts/clinic-security/up.sh ก่อน เพราะทรงของบทที่ 7 ต้องใช้ฐานข้อมูล
ชื่อ exception กับป้ายของ chain ถูกตรึงไว้ที่ src/data/perf/clinic-security.ts และ test/course-clinic-security.test.ts ผูกสิ่งที่บทนี้พิมพ์เข้ากับ file นั้น
Spring Security — Java Configuration (เข้าถึง 2026-09-02) — การประกาศหลาย SecurityFilterChain และ securityMatcher

เช็กความเข้าใจ — บทที่ 4

ข้อ 1 / 3

ประกาศ chain ที่ไม่มี `securityMatcher` ไว้เป็นตัวแรก แล้วเกิดอะไรขึ้น

chain ที่​วาง​ผิด​ลำดับ แล้ว​แอป​ไม่​ยอม​ส​ตาร์ต

สอง​ตัว หนึ่ง​กว้าง หนึ่ง​แคบ

ผม​คาด​ว่า​กฎ​จะ​เงียบ​หาย แต่​แอป​สร้าง bean ไม่​สำเร็จ​เลย

สลับ​ลำดับ แล้ว​วัด​ใหม่

กฎ​ที่​เหลือ​จาก​บท​นี้

สิ่ง​ที่​บท​นี้​ทิ้ง​ไว้