การเปิดเผย endpoint สาธารณะและส่วนตัว
GraphQL โดยดั้งเดิมมุ่งเน้นการเปิดเผย endpoint เดียว ซึ่งมักอยู่ภายใต้ https://mysite.com/graphql
Gato GraphQL ขยายแนวคิดนี้ โดยอนุญาตให้เราเปิดเผย endpoint แบบกำหนดเองหลายรายการ โดยแต่ละรายการถูกปรับแต่งให้ตอบสนองความต้องการเฉพาะ ตัวอย่างเช่น เราสามารถเปิดเผย endpoint ดังนี้:
/internalและ/public/apps/mobileและ/apps/website/clientsและ/visitors/development,/stagingและ/production/teams/development,/teams/testingและ/teams/marketing/clients/A,/clients/Bและclients/Z- หรือการผสมผสานใดๆ ของสิ่งเหล่านี้
Gato GraphQL ยังรองรับ Persisted Queries ซึ่งเป็น endpoint ที่ GraphQL queries ถูกกำหนดไว้ล่วงหน้าและจัดเก็บไว้บนเซิร์ฟเวอร์
คู่มือนี้นำเสนอคำแนะนำเกี่ยวกับวิธีการและเวลาที่ควรใช้แต่ละ endpoint
นอกจากการรักษาความปลอดภัย API endpoint ของ Gato GraphQL แล้ว เราขอแนะนำให้คุณเสริมความปลอดภัยให้กับเว็บไซต์ WordPress ของคุณอยู่เสมอโดยใช้ปลั๊กอินความปลอดภัยเฉพาะ เช่น WP Security Ninja
endpoint ได้รับการกำหนดค่าผ่าน Schema Configuration ซึ่งเราจะกำหนด:
- การตั้งค่า schema เป็นสาธารณะหรือส่วนตัว
- การเปิดใช้งานองค์ประกอบข้อมูลที่ "sensitive"
- การกำหนด namespace ให้กับ schema
- การใช้ nested mutations
- การกำหนด response headers
- การให้สิทธิ์เข้าถึงองค์ประกอบ schema ผ่าน Access Control Lists
- การตั้งค่า HTTP caching
- และอื่นๆ อีกมากมาย
หากเรามีการกำหนดค่าที่ต้องการใช้กับ endpoint ทั้งหมดหรือส่วนใหญ่ เราสามารถกำหนด default Schema Configuration ได้
เมื่อใดควรใช้ single endpoint
single endpoint เป็นสาธารณะเสมอ เปิดเผยโดยค่าเริ่มต้นภายใต้ /graphql
Gato GraphQL จัดการผ่าน "modules" โดยแต่ละ module มีฟังก์ชันการทำงานหรือการขยาย GraphQL schema และสามารถเปิดหรือปิดใช้งานได้ตามต้องการ
เพื่อเสริมความปลอดภัยของ API เป็นแนวทางที่ดีในการปิดใช้งาน module ที่ขยาย GraphQL schema (เช่น module "Posts", "Users", "Comments", "Blocks" เป็นต้น) เมื่อไม่จำเป็น เพื่อให้แน่ใจว่าข้อมูลนั้นจะไม่ถูกเปิดเผยตั้งแต่แรก
โดยเฉพาะอย่างยิ่ง หาก API ไม่ได้มีไว้เพื่อการเปลี่ยนแปลงข้อมูล (เช่น การสร้างหรืออัปเดตทรัพยากร) เป็นแนวทางที่ดีในการปิดใช้งาน module "Mutations" การทำเช่นนี้จะปิดใช้งานส่วนขยายทั้งหมดที่มี mutation (เช่น module "Post Mutations", "Comment Mutations" เป็นต้น) และ mutation เหล่านี้จะไม่ถูกเปิดเผยใน GraphQL schema
แนะนำให้ใช้ single endpoint เมื่อ:
- เราต้องการดึงข้อมูลเพื่อขับเคลื่อนฟีเจอร์เดียว และ
- เว็บไซต์ WordPress ไม่สามารถเข้าถึงได้จากอินเทอร์เน็ตสาธารณะ (เช่น กำลังรันบนแล็ปท็อปสำหรับการพัฒนา หรืออยู่เบื้องหลัง firewall)
กรณีนี้เกิดขึ้นเช่น ในการสร้างเว็บไซต์แบบ headless (โดยใช้ Next.js, Gatsby หรืออื่นๆ)
เมื่อใดควรใช้ public custom endpoints
Custom endpoints คล้ายกับ single endpoint แต่เราสามารถมีได้หลายรายการ โดยแต่ละรายการเปิดเผยภายใต้ URL ของตัวเอง graphql/{custom-endpoint-slug}/ และแต่ละรายการมีการกำหนดค่าที่แตกต่างกัน
Custom endpoints มอบความปลอดภัยผ่านการปิดบัง เนื่องจากเป้าหมายที่ตั้งใจไว้เท่านั้นควรรู้เกี่ยวกับการมีอยู่ของ custom endpoint และ URL ของมัน
เพื่อเพิ่มความปลอดภัยของ API เราสามารถใช้ส่วนขยาย Access Control เพื่อให้สิทธิ์เข้าถึง endpoint เฉพาะเมื่อ:
- ผู้ใช้เข้าสู่ระบบแล้ว (หรือยังไม่ได้เข้าสู่ระบบ)
- ผู้ใช้มี role บางอย่าง
- ผู้ใช้มี capability บางอย่าง
- ผู้เยี่ยมชมมาจาก IP ที่ได้รับอนุญาต (ผ่านส่วนขยาย Access Control: Visitor IP)
Custom endpoint แต่ละรายการสามารถมี Access Control List ของตัวเองได้ ทำให้สามารถเข้าถึงได้เฉพาะผู้ใช้ที่ตั้งใจไว้เท่านั้น
แนะนำให้ใช้ custom endpoints เมื่อเราต้องการจัดการและปรับแต่งการเข้าถึง API ไม่ว่าจะเป็นโดยแอปพลิเคชัน ทีม ลูกค้า หรือผู้อื่นที่แตกต่างกัน
เมื่อใดควรใช้ private custom endpoints
Gato GraphQL ใช้งาน custom endpoints ผ่าน Custom Post Types (CPTs) ซึ่งอนุญาตให้เราเผยแพร่ custom endpoint เป็น private (และยังเป็น password-protected ได้ด้วย) ทำให้ custom endpoint สามารถเข้าถึงได้เฉพาะผู้ใช้ที่เข้าสู่ระบบแล้วซึ่งมีสิทธิ์เข้าถึง custom post นั้น และไม่มีใครอื่น
วิธีนี้แนะนำเมื่อ GraphQL endpoint มีไว้เพื่อใช้โดยผู้ดูแลระบบของเว็บไซต์เท่านั้น (เช่น เมื่อใช้ GraphQL เพื่อดำเนินงานด้านการดูแลระบบ) การปิดกั้นผู้เยี่ยมชมภายนอกไม่ให้เข้าถึง endpoint อย่างสมบูรณ์จะช่วยเพิ่มความปลอดภัยของเว็บไซต์
เมื่อใดควรใช้ public Persisted Queries
Persisted queries คือ endpoint ที่แต่ละรายการมี URL ของตัวเอง แต่ GraphQL queries ได้ถูกกำหนดไว้ที่ฝั่งเซิร์ฟเวอร์แล้ว ดังนั้น response ก็ถูกกำหนดไว้ล่วงหน้าด้วย (สามารถทำให้ dynamic ได้โดยการกำหนดตัวแปร ที่รับค่าจาก URL params)
Persisted queries คล้ายกับ REST endpoints แต่เราใช้ภาษา GraphQL ในการประกอบ query และเราสามารถเผยแพร่ได้โดยตรงจาก wp-admin โดยไม่จำเป็นต้อง deploy โค้ด PHP เพื่อเผยแพร่ persisted query
เนื่องจาก persisted queries ไม่จำเป็นต้องส่ง GraphQL query ในส่วน body ของ request จึงเหมาะสมโดยธรรมชาติสำหรับการเข้าถึงผ่าน GET แทน POST
(single endpoint และ custom endpoints ยังสามารถเข้าถึงได้ผ่าน GET โดยการเพิ่ม param ?query={ GraphQL query } ต่อท้าย endpoint)
เราสามารถใช้ประโยชน์จากสิ่งนี้และทำให้ API เร็วขึ้นผ่าน HTTP Caching มาตรฐาน โดย cache GraphQL response ที่ฝั่ง client หรือที่ขั้นตอนกลางระหว่าง client และเซิร์ฟเวอร์ (เช่น CDN)
สิ่งนี้สำเร็จได้ผ่านส่วนขยาย Cache Control ซึ่งจะคำนวณและส่งออกค่า max-age ของ response โดยอัตโนมัติตาม field และ directive ที่มีอยู่ใน query
แนะนำให้ใช้ persisted queries เมื่อใดก็ตามที่เป็นไปได้ เนื่องจากช่วยเพิ่มความปลอดภัยของเว็บไซต์อย่างมาก
เหตุผลคือข้อมูลทั้งหมดที่ต้องการให้เข้าถึงได้สำหรับแอปพลิเคชันของเราสามารถเปิดเผยผ่าน persisted queries ได้แล้ว จากนั้น เราสามารถหลีกเลี่ยงการเปิดเผย GraphQL single endpoint (หรือ custom endpoint ใดๆ) ซึ่งจะขจัดความเสี่ยงที่ผู้ใช้จะสามารถเข้าถึงข้อมูลส่วนตัวที่เราเผยแพร่ทิ้งไว้ (ไม่ว่าจะโดยตั้งใจหรือไม่)
เมื่อใดควรใช้ private Persisted Queries
คล้ายกับ custom endpoints, persisted queries เป็น CPTs ดังนั้นเราสามารถเผยแพร่เป็น private (หรือ password-protected) ทำให้สามารถเข้าถึงได้เฉพาะผู้ใช้ที่เข้าสู่ระบบแล้วซึ่งมีสิทธิ์เข้าถึงและไม่มีใครอื่น
แนะนำให้ใช้สิ่งเหล่านี้เมื่อใดก็ตามที่ query มีไว้เพื่อใช้งานภายในเท่านั้น เช่น เมื่อค้นหาข้อมูล WordPress สำหรับการใช้งานของเราเอง