繁體中文（台灣）
精通 Logto 中的 RBAC：一個全面的實際範例
本文提供了一個關於掌握 Logto 中基於角色的訪問控制 (RBAC) 的全面指南，使用一家線上書店的實際範例來探索主要的用戶角色、範圍，以及在前端和後端應用中整合 Logto 的 RBAC 功能以增強安全性和訪問控制。
Sijie
Developer
Developer
本文提供了一個關於掌握 Logto 中基於角色的訪問控制 (RBAC) 的全面指南，使用一家線上書店的實際範例來探索主要的用戶角色、範圍，以及在前端和後端應用中整合 Logto 的 RBAC 功能以增強安全性和訪問控制。
訪問控制和安全性是現代應用程式的關鍵要素，確保用戶擁有適當的資源訪問權限。Logto 的基於角色的訪問控制 (RBAC) 提供給開發者一種高效管理應用程式中訪問控制和安全性的方法。在本文中，我們將通過一個實際的範例來探索 Logto 的 RBAC 實現的強大功能，幫助你理解和應用這些概念到你的專案中。
通過檢查前端和後端的程式碼片段，你將獲得整合 Logto 的 RBAC 到你的應用程式堆栈的全面視角。到本文結束時，你將能夠利用 Logto 的 RBAC 功能來增強你專案的安全性和訪問控制。
為了有效展示 Logto 的 RBAC 功能，我們將使用一個實際的範例：BookHarber，一家線上書店。BookHarber 為顧客和員工提供了廣泛的功能，確保無縫且安全的購物體驗。
BookHarber 的主要功能包括：
在 BookHarber 生態系統中，我們可以識別出幾個主要的用戶角色，例如：
為了有效實現 Logto 的 RBAC 系統，我們需要設計與各個 REST API 對應的範圍。範圍是定義特定角色對每個 API 端點的訪問級別的權限。通過將適當的範圍分配給每個用戶角色，我們可以確保用戶只訪問與其角色相關的操作和資源。
讓我們為以下 REST API 設計範圍：
create:categories: POST /categorieswrite:categories: PUT /categories/:iddelete:categories: DELETE /categories/:idlist:categories: GET /categoriescreate:books: POST /bookswrite:books: PUT /books/:iddelete:books: DELETE /books/:idlist:books: GET /booksread:books: GET /books/:idlist:customers: GET /customerswrite:customers: PUT /customers/:iddelete:customers: DELETE /customers/:idread:customers: GET /customers/:idcreate:orders: POST /orderslist:orders: GET /ordersread:orders: GET /orders/:idwrite:orders: PUT /orders/:idcreate:events: POST /eventswrite:events: PUT /events/:idlist:events: GET /eventsdelete:events: DELETE /events/:idread:orderTracks: GET /orders/:id/trackscreate:orderTracks: POST /orders/:id/trackswrite:orderTracks: PUT /orders/:id/tracks/:trackIdcreate:tickets: POST /ticketslist:tickets: GET /ticketsread:tickets: GET /tickets/:idwrite:tickets: PUT /tickets/:id現在我們已經為每個 REST API 定義了適當的範圍，我們可以將這些範圍分配給 BookHarber 生態系統中的相應用戶角色：
| 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 | ✓ | ✓ |
為了進一步說明在 REST API 設計和 RBAC 中 "list" 和 "read" 範圍之間的區別，讓我們考慮一個涉及線上書店 BookHarber 的實際範例。
假設 BookHarber 有兩種類型的用戶：顧客和客戶服務代理。顧客可以創建訂單，而客戶服務代理負責幫助顧客處理訂單。讓我們看看 "list" 和 "read" 範圍如何應用於 orders API 資源中的這種情況。
list:orders 範圍允許用戶檢索所有可用訂單的列表。在 BookHarber 的情境中，這個範圍可以對於需要了解系統中所有訂單概覽的商店管理員或其他員工有用。然而，客戶服務代理不應該能夠訪問所有訂單，因為他們的角色是協助個別顧客工作。read:orders 範圍允許用戶根據其 ID 查看特定訂單的詳細信息。在 BookHarber 的情境中，這個範圍對需要訪問特定顧客訂單信息的客戶服務代理非常理想。當顧客開啟一個支援票據時，客戶服務代理可以使用票據中提供的訂單 ID 來訪問和查看該特定訂單的詳細信息。在許多應用中，通常用戶可以訪問自己的資源而無需明確授予相應的 "read" 或 "list" 範圍。這是因為用戶被認為是這些資源的所有者，應自然擁有它們的訪問權。在我們的 BookHarber 範例中，顧客可以創建訂單，但不需要 "read:orders" 或 "list:orders" 範圍。
所有權的概念在為 REST API 的特定資源定義訪問控制中發揮關鍵作用。通過承認用戶可以始終訪問他們的資源，我們可以實施更高效和安全的訪問控件，無需授予不必要的權限。在 BookHarber 的情況中，這意味著顧客可以查看和管理他們的訂單而不需要任何額外的範圍。
為了演示這是如何運作的，讓我們考慮 GET /orders 端點：
list:orders 範圍（例如，商店管理員或員工），他們將能夠查看系統中的所有訂單。這提供了他們角色所需的訂單數據的全面視圖。list:orders 範圍（例如，普通顧客），系統將僅返回屬於用戶的訂單。這確保顧客可以依然訪問他們的訂單信息，而無需授予不必要的權限。通過實施這種基於所有權的訪問控件，API 可以根據不同用戶角色提供適當的訪問水平，同時保持安全性和量身定制的用戶體驗。在 BookHarber 的場景中，所有權模型允許顧客訪問他們的訂單信息，而不需要 "read:orders" 或 "list:orders" 範圍，簡化訪問控制設計並增強整體用戶體驗。
要在 Logto 的控制台中完成配置，請按照以下步驟：
https://api.bookharber.com 的新的 API 資源。在我們的例子專案 BookHarber 中，我們使用 Express 作為後端服務和 React 作為前端網頁。本節將簡要概述如何將 Logto 的 RBAC 功能整合到這些流行技術中，以保護我們的應用程式。
完整文檔：https://docs.logto.io/docs/recipes/rbac/protect-resource
如要在你的 React 應用中初始化 Logto，請遵循此處提供的文檔：https://docs.logto.io/docs/recipes/integrate-logto/react/
除了基本設置之外，你還需要在配置中指定 "resource" 和 "scopes"：
以下是一個使用 Logto 發出 API 請求的例子：
如要保護 API，請遵循：https://docs.logto.io/docs/recipes/protect-your-api/
除了示例程式碼以外（https://docs.logto.io/docs/recipes/protect-your-api/node），我們還需要添加範圍驗證：
Logto 的 RBAC 系統是一種強大的工具，用於管理現代應用程式中的訪問控制和安全性。通過利用 Logto 的 RBAC 功能，你可以確保用戶根據其角色擁有適當的資源訪問權限，保護敏感數據和功能免受未經授權的訪問。
在本文中，我們探討了一個線上書店 BookHarber 的實際範例，並展示如何設計範圍、將其分配給用戶角色，以及在應用程式的前端和後端實現 Logto 的 RBAC 功能。
通過將這些概念和技術應用到你的專案，你可以增強應用程式的安全性和訪問控制，並提供一個無縫且安全的用戶體驗。無論你正在開發電子商務平台、內容管理系統或任何其他需要基於角色的訪問控制的專案，Logto 的 RBAC 系統都提供了一個靈活且高效的解決方案，以滿足你的訪問控制需求。