Vue 3 routing guards สำหรับการเข้าถึงตามบทบาท: รูปแบบใช้งานจริง

สิ่งที่ route guards แก้ไขได้จริง (และสิ่งที่แก้ไม่ได้)

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

การซ่อนเมนูเป็นเพียงสัญญาณ ไม่ใช่การอนุญาต ผู้คนยังสามารถพิมพ์ URL รีเฟรชที่ลิงก์ลึก หรือเปิดบุ๊กมาร์กได้ ถ้าการป้องกันมีเพียง “ปุ่มไม่แสดง” คุณก็ไม่มีการป้องกันจริงๆ

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

Guards ช่วยให้คุณ:

• บล็อกหน้าได้ก่อนที่จะแสดงผล
• เปลี่ยนเส้นทางไปหน้าเข้าสู่ระบบหรือค่าเริ่มต้นที่ปลอดภัย
• แสดงหน้าชัดเจน 401/403 แทนมุมมองที่พัง
• หลีกเลี่ยงลูปการนำทางโดยไม่ได้ตั้งใจ

สิ่งที่ guards ทำไม่ได้ก็คือการปกป้องข้อมูลด้วยตัวเอง หาก API ส่งข้อมูลสำคัญมายังเบราว์เซอร์ ผู้ใช้ยังสามารถเรียกจุดส่งข้อมูลนั้นโดยตรง (หรือดูการตอบกลับใน dev tools) ได้แม้ว่าหน้าจะถูกบล็อก การอนุญาตที่แท้จริงต้องเกิดขึ้นที่เซิร์ฟเวอร์ด้วย

เป้าหมายที่ดีคือครอบคลุมทั้งสองด้าน: บล็อกหน้าและบล็อกข้อมูล หากเจ้าหน้าที่ซัพพอร์ตเปิด route เฉพาะแอดมิน guard ควรหยุดการนำทางและแสดง “Access denied” แยกจากนั้น backend ของคุณควรปฏิเสธการเรียก API ที่สำหรับแอดมินเท่านั้น ดังนั้นข้อมูลที่จำกัดจะไม่ถูกส่งกลับ

เลือกรูปแบบบทบาทและสิทธิ์ที่เรียบง่าย

การควบคุมการเข้าถึงจะยุ่งยากเมื่อคุณเริ่มด้วยรายการบทบาทยาว ๆ เริ่มจากชุดเล็กที่คนเข้าใจจริง แล้วค่อยเพิ่มสิทธิ์ละเอียดเมื่อเจอปัญหา

การแยกที่ใช้ง่ายคือ:

• Roles อธิบายว่าใครคนนั้นเป็นใครในแอป
• Permissions อธิบายว่าพวกเขาทำอะไรได้บ้าง

สำหรับเครื่องมือภายในส่วนใหญ่ สามบทบาทครอบคลุมได้มาก:

• admin: จัดการผู้ใช้และการตั้งค่า เห็นข้อมูลทั้งหมด
• support: จัดการบันทึกลูกค้าและตอบกลับ แต่ไม่เห็นการตั้งค่าระบบ
• viewer: เข้าดูได้อย่างเดียวในหน้าที่อนุมัติแล้ว

ตัดสินใจตอนต้นว่าบทบาทมาจากไหน ส่วน claims ใน token (เช่น JWT) เร็วสำหรับ guards แต่ข้อมูลอาจล้าหลังจนกว่าจะรีเฟรช การดึงโปรไฟล์ผู้ใช้ตอนเริ่มแอปจะเป็นปัจจุบันเสมอ แต่ guards ต้องรอให้คำขอนั้นเสร็จ

แยกประเภท route อย่างชัดเจน: เส้นทางสาธารณะ (ทุกคนเข้าถึงได้), เส้นทางต้องพิสูจน์ตัวตน (ต้องมี session), และเส้นทางจำกัด (ต้องมีบทบาทหรือสิทธิ์)

กำหนดกฎการเข้าถึงด้วย route meta

วิธีที่สะอาดที่สุดในการระบุการเข้าถึงคือประกาศบน route เอง Vue Router ให้คุณแนบวัตถุ meta ในแต่ละ route record เพื่อให้ guards อ่านภายหลัง วิธีนี้ทำให้กฎอยู่ใกล้หน้าที่ถูกป้องกัน

เลือกโครง meta ที่เรียบง่ายแล้วยึดตามมันทั่วทั้งแอป

const routes = [
  {
    path: "/admin",
    component: () => import("@/pages/AdminLayout.vue"),
    meta: { requiresAuth: true, roles: ["admin"] },
    children: [
      {
        path: "users",
        component: () => import("@/pages/AdminUsers.vue"),
        // inherits requiresAuth + roles from parent
      },
      {
        path: "audit",
        component: () => import("@/pages/AdminAudit.vue"),
        meta: { permissions: ["audit:read"] },
      },
    ],
  },
  {
    path: "/tickets",
    component: () => import("@/pages/Tickets.vue"),
    meta: { requiresAuth: true, permissions: ["tickets:read"], readOnly: true },
  },
]

สำหรับ nested routes ตัดสินใจว่ากฎจะรวมกันอย่างไร ในแอปส่วนใหญ่ ลูกควรสืบทอดข้อกำหนดจากพ่อ ใน guard ของคุณให้ตรวจทุก matched route record (ไม่ใช่แค่ to.meta) เพื่อไม่ให้ข้อกำหนดของพ่อถูกข้าม

รายละเอียดหนึ่งที่ช่วยประหยัดเวลา: แยกระหว่าง “ดูได้” กับ “แก้ไขได้” หน้าอาจมองเห็นได้ทั้ง support และ admin แต่การแก้ไขควรถูกปิดสำหรับ support ธง readOnly: true ใน meta สามารถควบคุมพฤติกรรม UI (ปิดการใช้งานปุ่ม กระทำที่ทำลาย) โดยไม่อ้างว่าเป็นการรักษาความปลอดภัย

เตรียมสถานะ auth เพื่อให้ guards ทำงานได้เชื่อถือได้

บั๊กของ guard ส่วนใหญ่เกิดจากปัญหาเดียว: guard ทำงานก่อนที่แอปจะรู้ว่าผู้ใช้เป็นใคร

มอง auth เหมือนเครื่องสถานะขนาดเล็กและทำให้มันเป็นแหล่งข้อมูลเดียวที่เชื่อถือได้ คุณต้องการสามสถานะชัดเจน:

• unknown: แอปเพิ่งเริ่ม ยังไม่ได้ตรวจเซสชัน
• logged out: การตรวจเซสชันเสร็จแล้ว ไม่มีผู้ใช้ที่ถูกต้อง
• logged in: โหลดผู้ใช้เรียบร้อย บทบาท/สิทธิ์พร้อม

กฎคือ: อย่าอ่านบทบาทเมื่อ auth เป็น unknown นั่นคือสาเหตุที่เกิดการกระพริบของหน้าที่ต้องป้องกันหรือการเปลี่ยนเส้นทางไปหน้าเข้าสู่ระบบโดยไม่คาดคิด

ตัดสินใจวิธีรีเฟรชเซสชัน

เลือกกลยุทธ์รีเฟรชหนึ่งแบบและทำให้มันคาดการณ์ได้ (ตัวอย่าง: อ่าน token เรียก endpoint “who am I” แล้วตั้งค่าผู้ใช้)

รูปแบบที่มั่นคงจะเป็นดังนี้:

• ตอนโหลดแอป ตั้งค่า auth เป็น unknown และเริ่มคำขอรีเฟรชครั้งเดียว
• ตัดสิน guards หลังคำขอรีเฟรชเสร็จ (หรือหมดเวลา)
• แคชผู้ใช้ในหน่วยความจำ ไม่เก็บใน route meta
• หากล้มเหลว ให้ตั้งค่า auth เป็น logged out
• เปิดเผย promise ready (หรือสิ่งที่คล้ายกัน) ที่ guards จะรอ

เมื่อมีสิ่งนี้อยู่แล้ว ตรรกะ guard จะเรียบง่าย: รอให้ auth พร้อม แล้วตัดสินการเข้าถึง

ขั้นตอนทีละขั้น: การใช้ authorization ระดับ route

แนวทางที่สะอาดคือเก็บกฎส่วนใหญ่ไว้ใน global guard เดียว และใช้ per-route guards เมื่อเส้นทางนั้นต้องการตรรกะพิเศษจริง ๆ

1) เพิ่ม global beforeEach guard

// router/index.js
router.beforeEach(async (to) => {
  const auth = useAuthStore()

  // Step 2: wait for auth initialization when needed
  if (!auth.ready) await auth.init()

  // Step 3: check authentication, then roles/permissions
  if (to.meta.requiresAuth && !auth.isAuthenticated) {
    return { name: 'login', query: { redirect: to.fullPath } }
  }

  const roles = to.meta.roles
  if (roles && roles.length > 0 && !roles.includes(auth.userRole)) {
    return { name: 'forbidden' } // 403
  }

  // Step 4: allow navigation
  return true
})

นี่ครอบคลุมเหตุการณ์ส่วนใหญ่โดยไม่ต้องกระจายการตรวจสอบใน components

เมื่อ beforeEnter เหมาะสมกว่า

ใช้ beforeEnter เมื่อกฎเป็นเฉพาะเส้นทางจริง ๆ เช่น “เฉพาะเจ้าของตั๋วเท่านั้นที่เปิดหน้านี้ได้” และขึ้นกับ to.params.id ให้สั้นและใช้ auth store เดียวกันเพื่อพฤติกรรมสอดคล้องกัน

การเปลี่ยนเส้นทางอย่างปลอดภัยโดยไม่เปิดช่องโหว่

การเปลี่ยนเส้นทางอาจทำลายการควบคุมการเข้าถึงได้อย่างเงียบ ๆ ถ้าคุณถือว่าพวกมันเชื่อถือได้

รูปแบบทั่วไปคือ: เมื่อผู้ใช้ยังไม่ล็อกอิน ส่งไปหน้า Login และใส่พารามิเตอร์ returnTo หลังล็อกอินอ่านค่าแล้วนำทางไปที่นั่น ความเสี่ยงคือ open redirects (ส่งผู้ใช้ไปที่อื่นที่ไม่คาดคิด) และลูป

ทำให้พฤติกรรมเรียบง่าย:

• ผู้ใช้ที่ยังไม่ล็อกอินไปหน้า Login โดยมี returnTo เป็น path ปัจจุบัน
• ผู้ที่ล็อกอินแล้วแต่ไม่มีสิทธิ์ ให้ไปหน้า Forbidden แยกต่างหาก (ไม่ใช่ Login)
• อนุญาต returnTo เฉพาะค่าภายในที่คุณรู้จักเท่านั้น
• เพิ่มการตรวจลูปหนึ่งจุดเพื่อไม่ให้เปลี่ยนเส้นทางไปที่เดิม

const allowedReturnTo = (to) => {
  if (!to || typeof to !== 'string') return null
  if (!to.startsWith('/')) return null
  // optional: only allow known prefixes
  if (!['/app', '/admin', '/tickets'].some(p => to.startsWith(p))) return null
  return to
}

router.beforeEach((to) => {
  if (!auth.isReady) return false

  if (!auth.isLoggedIn && to.name !== 'Login') {
    return { name: 'Login', query: { returnTo: to.fullPath } }
  }

  if (auth.isLoggedIn && !canAccess(to, auth.user) && to.name !== 'Forbidden') {
    return { name: 'Forbidden' }
  }
})

หลีกเลี่ยงการรั่วไหลของข้อมูลที่ถูกจำกัดในระหว่างการนำทาง

การรั่วไหลที่ง่ายที่สุดคือการโหลดข้อมูลก่อนที่คุณจะรู้ว่าผู้ใช้ได้รับอนุญาตให้ดูมันหรือไม่

ใน Vue มักเกิดเมื่อหน้าดึงข้อมูลใน setup() แล้ว guard ทำงานทีหลัง แม้ว่าผู้ใช้จะถูกเปลี่ยนเส้นทาง คำตอบอาจตกลงในสโตร์ที่แชร์หรือปรากฏบนหน้าชั่วคราว

กฎที่ปลอดภัยคือ: ตรวจสิทธิ์ก่อน แล้วค่อยโหลด

// router guard: authorize before entering the route
router.beforeEach(async (to) => {
  await auth.ready() // ensure roles are known
  const required = to.meta.requiredRole
  if (required && !auth.hasRole(required)) {
    return { name: 'forbidden' }
  }
})

นอกจากนี้ให้ระวังคำขอล่าช้าตอนที่การนำทางเปลี่ยนเร็ว ยกเลิกคำขอ (เช่นด้วย AbortController) หรือเพิกเฉยต่อคำตอบที่มาช้าด้วยการเช็ค request id

การแคชก็เป็นกับดักอีกอย่าง ถ้าคุณเก็บ “เรคคอร์ดลูกค้าที่โหลดล่าสุด” อย่างเป็น global คำตอบสำหรับแอดมินอาจถูกแสดงภายหลังให้ผู้ใช้ที่ไม่ใช่แอดมินเห็น ให้คีย์แคชตาม user id และ role และล้างโมดูลที่ละเอียดอ่อนเมื่อ logout (หรือเมื่อบทบาทเปลี่ยน)

นิสัยเล็ก ๆ ที่ป้องกันการรั่วส่วนใหญ่:

• อย่าดึงข้อมูลที่ละเอียดอ่อนจนกว่าจะยืนยันสิทธิ์
• คีย์แคชด้วย user และ role หรือเก็บไว้ локальний ในหน้า
• ยกเลิกหรือเพิกเฉยต่อคำขอที่ยังรันเมื่อ route เปลี่ยน

หน้าสำรองที่เป็นมิตร: 401, 403, และ not found

เส้นทางที่ตอบว่า “ไม่” สำคัญไม่แพ้เส้นทางที่ตอบว่า “ใช่” หน้าสำรองที่ดีช่วยให้ผู้ใช้ไม่หลงทางและลดคำขอซัพพอร์ต

401: ต้องเข้าสู่ระบบ (ยังไม่ได้พิสูจน์ตัวตน)

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

403: ปฏิเสธการเข้าถึง (ล็อกอินแล้วแต่ไม่มีสิทธิ์)

ใช้ 403 เมื่อผู้ใช้ล็อกอินแล้วแต่ขาดสิทธิ์ ให้รักษาน้ำเสียงเป็นกลางและหลีกเลี่ยงการบอกรายละเอียดที่ละเอียดอ่อน

หน้า 403 ที่ดีมักมีชื่อชัดเจน (“Access denied”) คำอธิบายสั้น ๆ หนึ่งประโยค และทางเลือกที่ปลอดภัยถัดไป (กลับไปแดชบอร์ด ติดต่อแอดมิน หรือสลับบัญชีถ้ารองรับ)

404: ไม่พบหน้า

จัดการ 404 แยกจาก 401/403 มิฉะนั้นคนจะคิดว่าพวกเขาไม่มีสิทธิ์เมื่อจริง ๆ แล้วหน้าไม่มีอยู่

ข้อผิดพลาดทั่วไปที่ทำให้การควบคุมการเข้าถึงพัง

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

สาเหตุที่พบบ่อย:

• ถือว่า UI ที่ถูกซ่อนคือ “ความปลอดภัย” เสมอ ต้องบังคับบทบาททั้งใน router และใน API
• อ่านบทบาทจาก state ที่ล้าหลังหลัง logout/login
• เปลี่ยนเส้นทางผู้ใช้ที่ไม่ได้รับอนุญาตไปยัง route ที่ถูกป้องกันอีกที (เกิดลูปทันที)
• มองข้ามช่วงที่ “auth ยังโหลดอยู่” ตอนรีเฟรช
• สับสนระหว่าง 401 กับ 403 ทำให้ผู้ใช้สับสน

ตัวอย่างสมจริง: เจ้าหน้าที่ซัพพอร์ต logout แล้วแอดมินล็อกอินบนเครื่องคอมพ์ร่วมกัน ถ้า guard อ่านบทบาทจากแคชก่อนที่เซสชันใหม่จะยืนยัน คุณอาจบล็อกแอดมินผิดหรือแย่กว่านั้น คือเปิดให้เข้าชั่วคราวซึ่งไม่ควรเปิด

เช็คลิสต์ด่วนก่อนปล่อย

ทำการตรวจสั้น ๆ มุ่งที่ช่วงเวลาที่การควบคุมการเข้าถึงมักพัง: เครือข่ายช้า เซสชันหมดอายุ และ URL ที่บุ๊กมาร์กไว้

• ทุกเส้นทางที่ต้องป้องกันมี meta กำหนดชัดเจน
• Guards จัดการสถานะการโหลด auth โดยไม่ให้กระพริบ UI ที่ป้องกัน
• ผู้ที่ไม่มีสิทธิ์ลงเอยที่หน้า 403 ชัดเจน (ไม่ใช่เด้งกลับไปหน้าแรกอย่างสับสน)
• ทุกการเปลี่ยนเส้นทางแบบ “กลับไป” ถูกตรวจและไม่สร้างลูป
• การเรียก API ที่ละเอียดอ่อนรันก็ต่อเมื่อยืนยันสิทธิ์แล้ว

จากนั้นทดสอบหนึ่งสถานการณ์แบบ end-to-end: เปิด URL ที่ต้องป้องกันในแท็บใหม่ขณะที่ยังไม่ได้ล็อกอิน ล็อกอินเป็นผู้ใช้พื้นฐาน แล้วยืนยันว่าคุณจะไปถึงหน้าที่ตั้งใจไว้ (ถ้าอนุญาต) หรือหน้า 403 ที่ชัดเจนพร้อมขั้นตอนต่อไป

ตัวอย่าง: การเข้าถึงของ support vs admin ในเว็บแอปเล็ก ๆ

สมมติแอป helpdesk มีสองบทบาท: support และ admin Support อ่านและตอบตั๋วได้ แอดมินทำได้เช่นกัน และจัดการบิลและการตั้งค่าบริษัทได้

• /tickets/:id อนุญาตสำหรับ support และ admin
• /settings/billing อนุญาตเฉพาะ admin

ช่วงเวลาทั่วไป: เจ้าหน้าที่ support เปิดลิงก์ลึกไปยัง /settings/billing จากบุ๊กมาร์กเก่า Guard ควรตรวจ meta ของ route ก่อนที่หน้าจะโหลดและบล็อกการนำทาง เพราะผู้ใช้ล็อกอินแต่ขาดบทบาท พวกเขาควรจบที่ fallback ปลอดภัย (403)

สองข้อความที่สำคัญ:

• ต้องล็อกอิน (401): “โปรดลงชื่อเข้าใช้เพื่อดำเนินการต่อ.”
• ปฏิเสธการเข้าถึง (403): “คุณไม่มีสิทธิ์เข้าถึงการตั้งค่าบิล.”

สิ่งที่ไม่ควรเกิดขึ้น: คอมโพเนนต์ billing ถูก mount หรือข้อมูล billing ถูกดึงแม้เพียงชั่วคราว

การเปลี่ยนบทบาทระหว่าง session ก็เป็นกรณีขอบเช่นกัน หากใครสักคนได้รับเลื่อนขั้นหรือถูกลดบทบาท อย่าไว้วางใจเมนู รีเช็กบทบาทเมื่อมีการนำทางและตัดสินใจว่าจะจัดการหน้าที่กำลังเปิดอยู่ยังไง: รีเฟรชสถานะ auth เมื่อโปรไฟล์เปลี่ยน หรือสังเกตการเปลี่ยนบทบาทแล้วเปลี่ยนเส้นทางออกจากหน้าที่ไม่อนุญาต

ขั้นตอนถัดไป: ทำให้กฎการเข้าถึงคงที่และดูแลได้

เมื่อ guards ทำงานแล้ว ความเสี่ยงใหญ่ถัดมาคือ drift: route ใหม่ไม่มี meta, บทบาทถูกเปลี่ยนชื่อ, และกฎไม่สอดคล้องกัน

เปลี่ยนกฎของคุณเป็นแผนทดสอบเล็ก ๆ ที่รันเมื่อเพิ่ม route:

• ในฐานะ Guest: เปิด route ที่ต้องป้องกันและยืนยันว่าคุณไปหน้า login โดยไม่เห็นเนื้อหาบางส่วน
• ในฐานะ User: เปิดหน้าที่คุณไม่ควรเข้าถึงและยืนยันว่าคุณได้หน้า 403 ชัดเจน
• ในฐานะ Admin: ลองลิงก์ลึกที่คัดลอกมาจากแถบที่อยู่
• สำหรับแต่ละบทบาท: รีเฟรชบน route ที่ต้องป้องกันและยืนยันผลคงที่

ถ้าต้องการความปลอดภัยเพิ่ม ให้เพิ่มมุมมองสำหรับ dev เท่านั้นหรือเอาต์พุตคอนโซลที่แสดงรายการ routes และ meta ของพวกมัน เพื่อให้กฎที่ขาดหายโดดเด่นทันที

หากคุณกำลังสร้างเครื่องมือภายในหรือพอร์ทัลด้วย AppMaster (appmaster.io) คุณสามารถใช้แนวทางเดียวกันได้: ให้ route guards มุ่งที่การนำทางใน Vue3 UI และบังคับสิทธิ์ที่ฝั่ง backend และข้อมูลอยู่

เลือกการปรับปรุงอย่างใดอย่างหนึ่งแล้วทำให้เสร็จ end-to-end: กั้นการดึงข้อมูลให้แน่นขึ้น ปรับปรุงหน้า 403 ให้ใช้งานได้จริงขึ้น หรือล็อกการจัดการ redirect การแก้ไขเล็ก ๆ เหล่านี้คือสิ่งที่หยุดบั๊กการเข้าถึงในโลกจริงได้ส่วนใหญ่