Lập trình viên / Tra cứu
Quản trị viên và quyền dữ liệu dùng chung
Bảng mới chỉ Admin truy cập. Cấp quyền cho người dùng bằng bộ quy tắc liên kết nhiều bảng, chọn riêng dòng và cột.
Bắt đầu: không cần viết quy tắc chặn từng bảng
Tạo hoặc nhập nhiều bảng: người dùng thường và khách chưa có quyền. Quản trị viên ứng dụng có is_admin=true được xem, thêm, sửa, xóa toàn bộ dữ liệu trong Project, kể cả bảng và cột tạo sau này. Không cần tạo một policy Admin cho mỗi bảng.
Bật quản trị viên tại Authentication → Người dùng: tìm email đã đăng ký, mở tài khoản đã xác minh rồi bật Quản trị viên ứng dụng. Quyền này không quản lý tài khoản Auth, khóa, cấu trúc Database, thanh toán hoặc Project.
1. Tạo bộ quy tắc
Mở Database → Quyền truy cập → Tạo bộ quy tắc. Đặt tên dễ hiểu, ví dụ Người dùng xem dữ liệu của mình. Chọn ai được truy cập và các thao tác Xem, Thêm, Sửa, Xóa.
Người đã đăng nhập, khách chưa đăng nhập, khóa server chỉ đọc và khóa server đọc/ghi là những danh tính độc lập. Vai trò nghiệp vụ trong các bảng roles, permissions, user_roles do ứng dụng của bạn tự thiết kế; WhyPik không tự hiểu hoặc tin chúng dựa vào tên bảng.
2. Chọn bảng, dòng và cột
Chọn nhiều bảng hoặc Chọn tất cả bảng. Chọn riêng cột cho Xem, Thêm và Sửa; Xóa áp dụng cả dòng. Nút Cho phép các cột hiện có chỉ lấy các cột tại thời điểm bấm. Cột mới thêm sau này vẫn bị chặn với người thường.
Điều kiện dòng hỗ trợ Mọi dòng, Dòng của người đăng nhập, Dòng thuộc nhóm tương thích cũ, hoặc cột boolean bằng true. Sở hữu dùng cột UUID identity:owner; nhóm dùng identity:group. Chọn cột điều kiện tương ứng trên từng bảng. Chưa hỗ trợ biểu thức SQL tùy ý hoặc tự tra bảng phân quyền nghiệp vụ.
3. Xem trước và áp dụng
Kiểm tra danh sách bảng bị ảnh hưởng, xác nhận rồi bấm Áp dụng quyền. Hàng đợi cập nhật PostgreSQL; chờ trạng thái sẵn sàng. Bộ quy tắc được liên kết, không sao chép: sửa một lần cập nhật các bảng đang liên kết.
Bảng mới không tự liên kết. Khi cần, mở bộ quy tắc để chọn bảng/cột mới rồi xác nhận. Xóa bộ quy tắc chỉ thu hồi quyền từ bộ đó, không xóa dữ liệu.
Quyền riêng và nhiều bộ quy tắc
Quyền riêng của từng bảng được giữ để thêm ngoại lệ. Các quyền cho phép được cộng thêm; bỏ một cột ở bộ này không phủ định quyền đã được cấp từ bộ khác. Khi điều kiện dòng và cột chồng nhau không thể kết hợp an toàn, WhyPik từ chối áp dụng và yêu cầu dùng cùng điều kiện dòng hoặc cùng tập cột.
Cấu trúc API dùng policy_sets ở cấp Database và policy_bindings trên từng bảng. Binding lưu danh sách cột cụ thể và cột điều kiện; không dùng wildcard. Chính sách riêng vẫn có subject, operation, columns, row; subject role:<UUID> dành cho cấu hình Auth cũ, không tự cấp quyền Admin.
Kiểm tra với người thật
Dùng Mô phỏng quyền cho khách, hai người dùng khác nhau và Admin. Sau đó kiểm tra request thật. Mô phỏng không chạy SQL, không chứng minh FK hoặc quota. Public key chỉ định danh Project; server vẫn kiểm tra phiên và quyền mỗi request.
Khôi phục backup Database giữ quyền hiện hành, không phục hồi quyền đã thu hồi trong backup. Tài khoản Auth và is_admin không nằm trong backup Database.
Quyền trong mode migration
Mode migration giữ nguyên mô hình is_admin, policy_sets, policy_bindings và các quyền hiện có. Editor quyền trực tiếp bị khóa; biểu diễn policy trong definition portable và ánh xạ role logic bằng file bindings từng môi trường. Không tự tạo quyền cho cột mới.
Plan hiển thị policy delta; --approve-policy là xác nhận riêng, không đồng nghĩa khóa được phép phê duyệt. Việc cấp/thu hồi role hoặc quyền liên quan khiến plan cũ phải được kiểm lại. Restore không tự mở lại quyền đã thu hồi.