Cơ sở kiến thức
Vai trò & cấp quyền
Vai trò nói ai đó được làm gì; quyền trên địa chỉ nói họ được làm điều đó với cái gì.
Chi tiết
- Hai loại quyền cho mỗi người, và cả hai phải đồng thuận thì mới có chuyện gì xảy ra. VAI TRÒ, đặt trong Settings → Members, nói họ được LÀM gì trong workspace: đọc thư, gửi thư, sửa mẫu, thêm tên miền, tạo API key. QUYỀN trên địa chỉ, đặt từ nút Share trên hàng của địa chỉ, nói họ được làm điều đó với những ĐỊA CHỈ nào, ở mức chỉ đọc hoặc đọc và gửi. Người giữ một vai trò có quyền gửi mà không có địa chỉ nào thì chẳng gửi được từ đâu cả; người giữ mọi địa chỉ trong workspace nhưng chỉ ở mức chỉ đọc thì cũng không gửi được từ địa chỉ nào.
- Sáu vai trò tồn tại sẵn mà không ai phải tạo, và mọi workspace đều có đúng sáu vai trò đó, nên “Admin” ở đây mang đúng nghĩa như trong tài liệu và trên API. Owner, Admin, Member và Viewer là một cái thang: mỗi bậc giữ mọi thứ bậc dưới có, nên hạ cấp ai đó sẽ thu hẹp phạm vi họ với tới được chứ không đổi sang một lát cắt khác. Developer và Billing không phải là bậc trên cái thang đó. Developer dựng tích hợp, nắm API key, webhook, mẫu và quyền gửi mà không đọc thư nào của workspace, còn Billing thấy gói dịch vụ và hóa đơn, đổi được gói và thông tin thanh toán trên đó, và đọc được cài đặt hộp thư mà không ghi được. Quyền của chúng có thể chỉnh sửa: một workspace không muốn thành viên sửa mẫu thì bỏ tick mục đó, và thay đổi có hiệu lực ở yêu cầu kế tiếp của bất kỳ ai giữ vai trò đó một cách TƯỜNG MINH. Người có vai trò vẫn chỉ được ngụ ý bởi một quyền trên địa chỉ được cấp từ trước khi vai trò tồn tại thì vẫn giữ mặc định ban đầu cho tới khi được cấp vai trò hẳn hoi. Tên của chúng cũng vậy: một workspace vận hành theo Ops và On-call cứ đổi tên chúng và thế là đang mô tả chính mình, đó mới là điều quan trọng.
- Owner là ngoại lệ theo mọi hướng: không sửa được, không xóa được, không gán được. Nó mô tả tài khoản mà workspace được gắn vào và giữ mọi quyền, kể cả những quyền được thêm ở bản phát hành sau, đó là lý do danh sách quyền của nó được tính ra chứ không lưu sẵn. Giao workspace cho người khác là một cuộc chuyển giao chứ không phải đổi vai trò, và ở đây không có gì làm việc đó.
- Ngoài những vai trò đó, một workspace tự viết vai trò của mình, tối đa 24 vai trò, bằng cách tick các quyền trong cùng một ma trận phân nhóm. Việc tick có tính kéo theo: “edit templates” lưu kèm “read templates”, bởi một vai trò sửa được mẫu mà không mở được mẫu là một ô tick ai đó quên chứ không phải chính sách ai đó cố ý. Xóa một vai trò đang có người hay API key nắm giữ sẽ hỏi chuyển họ sang đâu và từ chối thay vì đoán bừa. Một key mà vai trò biến mất sẽ rơi về chỗ hoàn toàn không có trần, tức là rộng hơn cả vai trò vừa mất.
- Một API key có thể được cấp gắn với một vai trò, và vai trò là trần chứ không phải một quyền thứ hai: những gì key được làm là scope của chính nó giao với quyền của vai trò, phân giải trên từng yêu cầu. Một key được tạo kèm quyền gửi nhưng bị chặn trần bởi Viewer thì không gửi được, và thu hẹp một vai trò sẽ thu hồi quyền ngay lập tức mà không cần xoay key. Trợ lý cũng bị ràng buộc bởi đúng danh sách đó, và MCP server dựng bộ công cụ của một client từ quyền của người gọi, nên client của một viewer hoàn toàn không có công cụ gửi trong đó, và mọi công cụ bị kiểm soát đều kiểm tra lại khi được gọi, bởi một phiên có thể đổi hộp thư sau khi danh sách đã được dựng.