การจัดการ RBAC ใน Logto: ตัวอย่างจริงที่ครอบคลุม

\n\n## บทนำ\n\nการควบคุมการเข้าถึงและความปลอดภัยเป็นส่วนสำคัญของแอปพลิเคชันสมัยใหม่ มั่นใจได้ว่าผู้ใช้จะมีการเข้าถึงทรัพยากรที่เหมาะสม การควบคุมการเข้าถึงตามบทบาท (RBAC) ของ Logto มอบวิธีที่มีประสิทธิภาพให้กับนักพัฒนาในการจัดการการควบคุมการเข้าถึงและความปลอดภัยในแอปพลิเคชันของพวกเขา ในบทความนี้ เราจะสำรวจคุณลักษณะที่ทรงพลังของการใช้งาน RBAC ของ Logto โดยใช้ตัวอย่างจริง ช่วยให้คุณเข้าใจและประยุกต์ใช้แนวคิดเหล่านี้กับโครงการของคุณ\n\nโดยการตรวจสอบทั้งโค้ดส่วนหน้าและส่วนหลัง คุณจะได้รับมุมมองที่ครอบคลุมเกี่ยวกับการรวม RBAC ของ Logto ลงไปในสแต็คแอปพลิเคชันของคุณ เมื่อสิ้นสุดบทความนี้ คุณจะมีความพร้อมในการใช้คุณลักษณะ RBAC ของ Logto เพื่อเพิ่มความปลอดภัยและการควบคุมการเข้าถึงของโครงการของคุณ\n\n

\n\n## แนะนำ BookHarber: กรณีศึกษาร้านหนังสือออนไลน์\n\nเพื่อแสดงให้เห็นถึงคุณลักษณะ RBAC ของ Logto อย่างมีประสิทธิภาพ เราจะใช้ตัวอย่างจริง: BookHarber, ร้านหนังสือออนไลน์ BookHarber นำเสนอฟีเจอร์หลากหลายให้แก่ลูกค้าและพนักงาน การันตีประสบการณ์การช้อปปิ้งที่ราบรื่นและปลอดภัย\n\nคุณลักษณะหลักของ BookHarber รวมถึง:\n\n1. การเรียกดูและซื้อหนังสือ: ผู้ใช้สามารถค้นหาและซื้อหนังสือจากคอลเลกชันที่หลากหลายได้อย่างง่ายดาย รวมทั้งหลากหลายแนวและผู้แต่ง\n2. การจัดการคำสั่งซื้อและการติดตามโลจิสติกส์: ลูกค้าที่ลงทะเบียนสามารถจัดการคำสั่งซื้อของพวกเขา ติดตามการขนส่ง และรับการอัปเดตในการซื้อ\n3. ข้อเสนอพิเศษและกิจกรรมในวันหยุด: BookHarber มอบส่วนลดพิเศษและโปรโมชั่นในช่วงกิจกรรมพิเศษและวันหยุดเพื่อดึงดูดและให้รางวัลกับฐานลูกค้าของตน\n4. การสนับสนุนลูกค้า: ลูกค้าสามารถเปิดตั๋วสนับสนุนเพื่อตอบคำถามหรือปัญหาใด ๆ ที่พวกเขาอาจเจอ และได้รับความช่วยเหลือจากเจ้าหน้าที่ของ BookHarber อย่างทันท่วงที\n5. การจัดการลูกค้า: พนักงานที่มีบทบาทต่างกันสามารถจัดการด้านต่าง ๆ ของแพลตฟอร์ม อาทิ บัญชีลูกค้า การประมวลผลคำสั่งซื้อ และการแก้ไขปัญหา\n\n## บทบาท\n\nในระบบนิเวศของ BookHarber เราสามารถระบุบทบาทผู้ใช้หลักหลายรายการได้ เช่น:\n\n1. แขก: ผู้ใช้ที่ไม่ได้ลงทะเบียนที่สามารถเรียกดูเว็บไซต์ ค้นหาหนังสือ และดูข้อเสนอพิเศษได้\n2. ลูกค้า: ผู้ใช้ที่ลงทะเบียนแล้วที่สามารถซื้อหนังสือ จัดการคำสั่งซื้อ ติดตามโลจิสติกส์ และเปิดตั๋วสนับสนุนได้\n3. ผู้ดูแลร้านค้า: พนักงานที่รับผิดชอบในการดูแลการจัดการและการดำเนินงานทั้งหมดของแพลตฟอร์ม พร้อมการเข้าถึงเต็มที่\n4. ผู้จัดการหนังสือ: พนักงานที่ดูแลการจัดการหนังสือและหมวดหมู่\n5. ตัวแทนฝ่ายบริการลูกค้า: พนักงานที่มีหน้าที่ตอบตั๋วสนับสนุน\n6. ผู้ให้บริการโลจิสติกส์ภายนอก: พันธมิตรภายนอกที่รับผิดชอบในการจัดการและติดตามการขนส่งและการจัดส่งคำสั่งซื้อ\n7. พนักงานการตลาด: พนักงานที่รับผิดชอบในการส่งเสริมการขายของ BookHarber รับผิดชอบการจัดการข้อเสนอพิเศษและกิจกรรม\n\n## การออกแบบขอบเขตสำหรับ REST API ของ BookHarber\n\nเพื่อการใช้งานระบบ RBAC ของ Logto สำหรับ BookHarber อย่างมีประสิทธิภาพ เราต้องออกแบบขอบเขตที่สอดคล้องกับ REST API ที่หลากหลาย ขอบเขตคือสิทธิ์ที่กำหนดระดับการเข้าถึงที่บทบาทที่เฉพาะเจาะจงมีสำหรับแต่ละ API endpoint โดยกำหนดขอบเขตที่เหมาะสมให้กับแต่ละบทบาทผู้ใช้ เราสามารถมั่นใจได้ว่าผู้ใช้จะสามารถเข้าถึงการกระทำและทรัพยากรที่เกี่ยวข้องกับบทบาทของตนเท่านั้น\n\nมาดูการออกแบบขอบเขตสำหรับ REST API ดังต่อไปนี้:\n\n1. Categories API:\n - create:categories: POST /categories\n - write:categories: PUT /categories/:id\n - delete:categories: DELETE /categories/:id\n - list:categories: GET /categories\n2. Books API:\n - create:books: POST /books\n - write:books: PUT /books/:id\n - delete:books: DELETE /books/:id\n - list:books: GET /books\n - read:books: GET /books/:id\n3. Customers API:\n - list:customers: GET /customers\n - write:customers: PUT /customers/:id\n - delete:customers: DELETE /customers/:id\n - read:customers: GET /customers/:id\n4. Orders API:\n - create:orders: POST /orders\n - list:orders: GET /orders\n - read:orders: GET /orders/:id\n - write:orders: PUT /orders/:id\n5. Events API:\n - create:events: POST /events\n - write:events: PUT /events/:id\n - list:events: GET /events\n - delete:events: DELETE /events/:id\n6. Order Tracks API:\n - read:orderTracks: GET /orders/:id/tracks\n - create:orderTracks: POST /orders/:id/tracks\n - write:orderTracks: PUT /orders/:id/tracks/:trackId\n7. Tickets API:\n - create:tickets: POST /tickets\n - list:tickets: GET /tickets\n - read:tickets: GET /tickets/:id\n - write:tickets: PUT /tickets/:id\n\n## การมอบหมายขอบเขตให้กับบทบาท\n\nตอนนี้ที่เราได้กำหนดขอบเขตที่เหมาะสมสำหรับแต่ละ REST API แล้ว เราสามารถมอบหมายขอบเขตเหล่านี้ให้กับบทบาทผู้ใช้ที่เกี่ยวข้องในระบบนิเวศของ BookHarber:\n\n| Scopes | Guest | Customer | Store Admin | Books Manager | Customer Service Agent | Third-Party Logistics Provider | Marketing Staff | | ------------------ | ----- | -------- | ----------- | ------------- | ---------------------- | ------------------------------ | --------------- | | create:categories | | | ✓ | ✓ | | | | | write:categories | | | ✓ | ✓ | | | | | delete:categories | | | ✓ | ✓ | | | | | list:categories | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | create:books | | | ✓ | ✓ | | | | | write:books | | | ✓ | ✓ | | | | | delete:books | | | ✓ | ✓ | | | | | list:books | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | read:books | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | list:customers | | | ✓ | | ✓ | | | | write:customers | | | ✓ | | | | | | delete:customers | | | ✓ | | | | | | read:customers | | | ✓ | | ✓ | | | | create:orders | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | list:orders | | | ✓ | | | | | | read:orders | | | ✓ | | ✓ | | | | write:orders | | | ✓ | | | | | | create:events | | | ✓ | | | | ✓ | | write:events | | | ✓ | | | | ✓ | | list:events | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | delete:events | | | ✓ | | | | ✓ | | read:orderTracks | | | ✓ | | ✓ | ✓ | | | create:orderTracks | | | ✓ | | | ✓ | | | write:orderTracks | | | ✓ | | | ✓ | | | create:tickets | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | list:tickets | | | ✓ | | ✓ | | | | read:tickets | | | ✓ | | ✓ | | | | write:tickets | | | ✓ | | ✓ | | |

การทำความเข้าใจความแตกต่างระหว่างขอบเขต "list" และ "read"\n\nเพื่อแสดงให้เห็นถึงความแตกต่างระหว่างขอบเขต "list" และ "read" ในบริบทของการออกแบบ REST API และ RBAC มาพิจารณาตัวอย่างจริงเกี่ยวกับร้านหนังสือออนไลน์ BookHarber\n\nสมมติว่า BookHarber มีผู้ใช้สองประเภท: ลูกค้าและตัวแทนฝ่ายบริการลูกค้า ลูกค้าสามารถสร้างคำสั่งซื้อได้ ในขณะที่ตัวแทนฝ่ายบริการลูกค้าจะรับผิดชอบในการช่วยลูกค้าด้วยคำสั่งซื้อของพวกเขา มาดูกันว่าขอบเขต "list" และ "read" จะใช้กับทรัพยากร API orders ในสถานการณ์นี้อย่างไร\n\n1. ขอบเขต List: ขอบเขต "list" อนุญาตให้ผู้ใช้เข้าถึงคอลเลกชันของเอนทิตีในระบบได้ ตัวอย่างเช่น ขอบเขต list:orders อนุญาตให้ผู้ใช้เรียกรายการคำสั่งซื้อทั้งหมดที่มีได้ ในบริบทของ BookHarber ขอบเขตนี้อาจมีประโยชน์สำหรับผู้ดูแลร้านค้าหรือพนักงานคนอื่น ๆ ที่ต้องการภาพรวมของคำสั่งซื้อทั้งหมดในระบบ แต่นายหน้าด้านบริการลูกค้าไม่ควรเข้าถึงรายการคำสั่งซื้อทั้งหมดได้ เนื่องจากบทบาทของพวกเขาคือการช่วยเหลือลูกค้ารายบุคคลในการสั่งซื้อของพวกเขา\n2. ขอบเขต Read: ขอบเขต "read" อนุญาตให้ผู้ใช้เข้าถึงเอนทิตีเดียวด้วย ID ที่กำหนด ตัวอย่างเช่น ขอบเขต read:orders อนุญาตให้ผู้ใช้ดูรายละเอียดข้อมูลเกี่ยวกับคำสั่งซื้อเฉพาะโดย ID ของมัน ในกรณีของ BookHarber ขอบเขตนี้เหมาะสำหรับตัวแทนฝ่ายบริการลูกค้าที่จำเป็นต้องเข้าถึงข้อมูลเกี่ยวกับคำสั่งซื้อของลูกค้ารายหนึ่ง เมื่อลูกค้าเปิดตั๋วสนับสนุน ตัวแทนฝ่ายบริการลูกค้าสามารถใช้ ID คำสั่งซื้อที่ระบุในตั๋วเพื่อเข้าถึงและดูรายละเอียดของคำสั่งซื้อนั้นได้\n\n## ความเข้าใจเกี่ยวกับความเป็นเจ้าของ: ทำไมลูกค้าไม่จำเป็นต้องใช้ขอบเขต "read" หรือ "list" สำหรับคำสั่งซื้อของตัวเอง\n\nในหลายแอปพลิเคชัน ผู้ใช้สามารถเข้าถึงทรัพยากรของตัวเองได้โดยไม่จำเป็นต้องมอบขอบเขต "read" หรือ "list" ให้กับพวกเขาอย่างชัดเจน นั่นเป็นเพราะผู้ใช้ถูกพิจารณาว่าเป็นเจ้าของทรัพยากรเหล่านี้และควรมีการเข้าถึงอย่างธรรมชาติ ในกรณีตัวอย่างของ BookHarber ลูกค้าสามารถสร้างคำสั่งซื้อได้แต่ไม่ได้ครอบครองขอบเขต "read:orders" หรือ "list:orders" ขึ้นอยู่กับแนวคิดของความเป็นเจ้าของในการกำหนดการควบคุมการเข้าถึงสำหรับทรัพยากรเฉพาะใน REST API โดยรับรู้ว่าผู้ใช้สามารถเข้าถึงทรัพยากรของตัวเองได้เสมอ เราสามารถใช้การควบคุมการเข้าถึงที่มีประสิทธิภาพและปลอดภัยยิ่งขึ้นโดยไม่ต้องให้สิทธิ์ที่ไม่จำเป็น สำหรับกรณีของ BookHarber นี้หมายความว่าลูกค้ายังสามารถดูและจัดการคำสั่งซื้อของพวกเขาได้โดยไม่ต้องมีขอบเขตเพิ่มเติมเพื่อแสดงให้เห็นว่าทำงานอย่างไร มาพิจารณา endpoint GET /orders:\n\n1. หากผู้ใช้มีขอบเขต list:orders (เช่น ผู้ดูแลร้านค้าหรือพนักงาน) พวกเขาจะสามารถดูคำสั่งซื้อทั้งหมดในระบบได้ ซึ่งให้มุมมองครอบคลุมของข้อมูลคำสั่งซื้อที่จำเป็นสำหรับบทบาทของพวกเขา\n2. หากผู้ใช้ไม่มีขอบเขต list:orders (เช่น ลูกค้าทั่วไป) ระบบจะส่งคืนเฉพาะคำสั่งซื้อที่เป็นของผู้ใช้เท่านั้น นี่เป็นการรับรองว่าลูกค้าสามารถเข้าถึงข้อมูลคำสั่งซื้อของพวกเขาได้โดยไม่ต้องมอบสิทธิ์ที่ไม่จำเป็น\n\nโดยการใช้การควบคุมการเข้าถึงตามความเป็นเจ้าของ API สามารถให้ระดับการเข้าถึงที่เหมาะสมแก่บทบาทผู้ใช้ที่แตกต่างกันในขณะที่ยังรักษาความปลอดภัยและประสบการณ์การใช้งานที่ปรับแต่ง ในสถานการณ์ของ BookHarber โมเดลความเป็นเจ้าของช่วยให้ลูกค้าเข้าถึงข้อมูลคำสั่งซื้อของพวกเขาได้โดยไม่ต้องมีขอบเขต "read:orders" หรือ "list:orders" ซึ่งช่วยให้การออกแบบการควบคุมการเข้าถึงเป็นเรื่องง่ายขึ้นและปรับปรุงประสบการณ์การใช้งานทั่วไป\n\n## การกำหนดค่าคอนฟิกใน Logto Console\n\nเพื่อให้การกำหนดค่าใน Logto Console สมบูรณ์ ให้ปฏิบัติตามขั้นตอนดังนี้:\n\n1. สร้างแอปพลิเคชันหน้าเดียว (SPA) สำหรับ React: ตั้งค่า SPA ใน Logto Console สำหรับแอปพลิเคชัน React ของคุณ\n2. สร้างทรัพยากร API: เพิ่มทรัพยากร API ใหม่ด้วยตัวระบุ https://api.bookharber.com\n3. กำหนดขอบเขตสำหรับทรัพยากร: สร้างขอบเขตที่จำเป็นภายใต้ทรัพยากร API ที่สร้างขึ้นใหม่\n4. สร้างบทบาทและมอบหมายขอบเขต: กำหนดบทบาทผู้ใช้สำหรับแอปพลิเคชันของคุณ และมอบหมายขอบเขตที่เหมาะสมให้กับแต่ละบทบาท\n5. มอบหมายบทบาทให้กับผู้ใช้: มอบหมายบทบาทที่เกี่ยวข้องให้กับผู้ใช้ในแอปพลิเคชันของคุณ มั่นใจได้ว่าผู้ใช้แต่ละราย (โดยเฉพาะพนักงาน) มีสิทธิ์ที่ถูกต้องตามบทบาทของพวกเขา\n\n## ป้องกัน API ด้วยการใช้ขอบเขต\n\nในโครงการตัวอย่างของเรา BookHarber เราใช้ Express สำหรับบริการส่วนหลังและ React สำหรับหน้าเว็บส่วนหน้า ส่วนนี้จะให้ภาพรวมคร่าว ๆ ถึงวิธีการรวมคุณลักษณะ RBAC ของ Logto ในเทคโนโลยียอดนิยมเหล่านี้เพื่อความปลอดภัยในแอปพลิเคชันของเรา\n\nเอกสารอย่างเต็ม: https://docs.logto.io/docs/recipes/rbac/protect-resource\n\n### ส่วนหน้า\n\nเพื่อเริ่มต้น Logto ในแอปพลิเคชัน React ของคุณ ให้ปฏิบัติตามเอกสารที่ให้ไว้ที่นี่:: https://docs.logto.io/docs/recipes/integrate-logto/react/\n\nนอกจากการกำหนดค่าพื้นฐานแล้ว คุณจะต้องระบุตัวตนและขอบเขตในคอนฟิก: \n#

\n\n## บทสรุป\n\nระบบ RBAC ของ Logto เป็นเครื่องมือที่มีพลังสำหรับการจัดการการควบคุมการเข้าถึงและความปลอดภัยในแอปพลิเคชันสมัยใหม่ โดยใช้คุณลักษณะ RBAC ของ Logto คุณสามารถมั่นใจได้ว่าผู้ใช้มีการเข้าถึงทรัพยากรที่เหมาะสมตามบทบาทของพวกเขา ปกป้องข้อมูลและฟังก์ชันสำคัญจากการเข้าถึงที่ไม่ได้รับอนุญาต\n\nในบทความนี้ เราได้สำรวจตัวอย่างจริงของร้านหนังสือออนไลน์ BookHarber และแสดงให้เห็นถึงวิธีการออกแบบขอบเขต การมอบหมายขอบเขตให้กับบทบาทผู้ใช้ และการใช้คุณลักษณะ RBAC ของ Logto ในส่วนหน้าและส่วนหลังของแอปพลิเคชัน\n\nโดยการประยุกต์ใช้แนวคิดและเทคนิคเหล่านี้กับโครงการของคุณ คุณสามารถเพิ่มความปลอดภัยและการควบคุมการเข้าถึงของแอปพลิเคชันของคุณ มั่นใจได้ประสบการณ์การใช้งานที่ราบรื่นและปลอดภัย ไม่ว่าคุณจะกำลังทำงานบนแพลตฟอร์มอีคอมเมิร์ซ ระบบจัดการเนื้อหา หรือโครงการใด ๆ ที่ต้องการควบคุมการเข้าถึงตามบทบาท ระบบ RBAC ของ Logto มีทางแก้ปัญหาที่ยืดหยุ่นและมีประสิทธิภาพเพื่อตอบสนองความต้องการด้านการควบคุมการเข้าถึงของคุณ\n\n
\n\n

\n