Chào mọi người, hôm nay mình sẽ giới thiệu tới mọi người một tính năng khá hay ho và tiện lợi trong Hasura đó chính là Permission. Một tính năng phân quyền giúp bạn kiểm soát dữ liệu một cách hiệu quả và chi tiết:
- Ai được phép truy cập dữ liệu?
- Có thể xem những cột nào, bản ghi nào?
- Được quyền thêm, sửa, hay xóa dữ liệu hay không?
Giờ hãy bắt đầu thôi nào 👉️👉️👉️
1. Hasura và Permission
Nếu bạn từng phát triển ứng dụng, chắc hẳn đã quen với cảnh phải viết hàng đống API endpoint để đọc dữ liệu, thêm dữ liệu, rồi lại phải cài thêm lớp kiểm soát quyền truy cập để đảm bảo ai được xem gì, ai được sửa gì. Việc này không chỉ tốn thời gian mà còn dễ sinh lỗi nếu hệ thống ngày càng phức tạp.
Đây chính là lúc Hasura bước vào. Hasura là một GraphQL Engine mạnh mẽ, có thể “hô biến” cơ sở dữ liệu của bạn thành API GraphQL chỉ trong vài phút. Nhưng điều làm Hasura trở nên đặc biệt không chỉ nằm ở tốc độ, mà còn ở Permission System – hệ thống phân quyền được tích hợp sẵn.
Điều này có nghĩa là bạn không cần phải vất vả code thủ công từng rule bảo mật. Thay vào đó, bạn có thể định nghĩa ngay trong Hasura:
- Ai được phép đọc dữ liệu?
- Người dùng nào có thể thêm, sửa hay xóa?
- Thông tin nào công khai, thông tin nào riêng tư?
Nhờ đó, bạn vừa có API “xịn” để phát triển nhanh, vừa đảm bảo dữ liệu luôn đúng người – đúng quyền. Nói cách khác, Hasura giúp bạn vừa chạy nhanh, vừa ngủ ngon.
2. Permission trong Hasura là gì?
Permission trong Hasura được hiểu là quy tắc xác định một người dùng có thể làm gì và với dữ liệu nào trong cơ sở dữ liệu.
Hasura quản lý Permission dựa trên 2 điểm:
- Role (vai trò): phạm vi được phép truy cập của người dùng, ví dụ:
user
,admin
,anonymous
. - Permission Rule (quy tắc phân quyền): Các điều kiện áp dụng cho role, xác định quyền Select, Insert, Update, Delete.
Ví dụ:
- Người dùng role
user
chỉ có thể xem dữ liệu của chính họ (row-level). - Role
admin
có thể truy cập toàn bộ dữ liệu mà không giới hạn. - Role
anonymous
chỉ có thể xem một số cột nhất định của bảng công khai.
3. Các loại Permission trong Hasura
Hasura hỗ trợ 4 loại quyền cơ bản cho mỗi bảng: Select (đọc), Insert (thêm), Update (sửa), Delete (xóa).
Điểm đặc biệt là bạn có thể áp dụng các rule chi tiết ở cả row-level (dòng dữ liệu) và column-level (cột dữ liệu). Điều này có
nghĩa là không chỉ “có/không có quyền”, mà còn có thể “có quyền nhưng chỉ trong điều kiện nào đó”.
3.1. Select (Đọc)
Dùng để: xác định ai được phép đọc dữ liệu và được đọc những cột nào, dòng nào.
-
Column-level: Ẩn cột nhạy cảm.
Ví dụ: bảngusers
có cộtpassword
. Với roleuser
, bạn có thể cho phép đọcid
,name
,email
, nhưng không cho phép đọcpassword
. -
Row-level: Chỉ hiển thị dữ liệu phù hợp với user.
Ví dụ: Trong bảngposts
, chỉ cho phép user đọc những đơn hàng cóuser_id
trùng vớiX-Hasura-User-Id
(ID người dùng hiện tại).
{ "user_id": { "_eq": "X-Hasura-User-Id" }
}
👉 Kết quả: Mỗi người dùng chỉ thấy đơn hàng của mình, không xem được đơn hàng của người khác.
3.2. Insert (Thêm)
Dùng để: xác định ai được phép thêm dữ liệu và giá trị nào sẽ được chấp nhận.
-
Có thể ép buộc một số cột bằng giá trị cố định hoặc từ user context.
-
Ví dụ: khi thêm bài viết (
posts
), bạn không muốn cho phép user tự ý chọnauthor_id
. Thay vào đó, Hasura sẽ tự động gánauthor_id
theo giá trị trong token của người dùng.
{ "check": {}, "set": { "author_id": "X-Hasura-User-Id" }
}
👉 Kết quả: Người dùng chỉ có thể tạo bài viết dưới tên của chính họ.
3.3. Update (Chỉnh sửa)
Dùng để: xác định ai được phép sửa dữ liệu, cột nào được sửa, và điều kiện để sửa.
- Giới hạn cột: Ví dụ, trong bảng
users
, cho phép user cập nhậtname
vàavatar
, nhưng không cho phép cập nhậtrole
. - Row-level rule: Chỉ cho phép sửa dữ liệu của chính mình.
Ví dụ với bảng posts
:
{ "author_id": { "_eq": "X-Hasura-User-Id" }
}
👉 Kết quả: User chỉ có thể chỉnh sửa bài viết mà họ đã tạo.
3.4. Delete (Xóa)
Dùng để: xác định ai được phép xóa dữ liệu, với điều kiện gì.
- Ví dụ: Trong bảng
posts
, chỉ cho phép user xóa bài viết cóuser_id
trùng với ID của họ.
{ "user_id": { "_eq": "X-Hasura-User-Id" }
}
👉 Kết quả: User không thể xóa posts của người khác, chỉ có admin mới có toàn quyền.
💡 Tóm lại:
Loại Permission | Ý nghĩa | Ví dụ |
---|---|---|
Select (Đọc) | Quy định ai được phép đọc dữ liệu, cột nào, dòng nào | User chỉ xem bài viết is_published = true , không xem cột password |
Insert (Thêm) | Quy định ai được phép thêm dữ liệu, và ép buộc giá trị cột | Khi user đăng bài mới, Hasura tự gán author_id = X-Hasura-User-Id |
Update (Sửa) | Quy định ai được phép sửa dữ liệu, cột nào được sửa, điều kiện gì | User chỉ sửa bài viết do chính họ tạo (author_id = X-Hasura-User-Id ) |
Delete (Xóa) | Quy định ai được phép xóa dữ liệu, với điều kiện nào | User chỉ xóa được comment của chính mình |
4. Cách thiết lập Permission trong Hasura
4.1. Xác định role
Trước tiên, bạn cần định nghĩa role cho ứng dụng. Role được truyền vào Hasura thông qua JWT claims hoặc request headers Và thường được dùng chung với Auth Service (như Auth0, Firebase Auth, Keycloak).
Khi user đăng nhập:
- Auth Service sinh ra JWT.
- JWT chứa claim role và user_id.
- Hasura dựa trên JWT để xác định Permission cho request đó.
Ví dụ, khi user đăng nhập, backend sẽ trả về token chứa claim:
{ "x-hasura-user-id": "123", "x-hasura-role": "user"
}
4.2. Thiết lập Permission trong
- Chọn bảng mà bạn muốn phân quyền.
- Chọn tab Permissions.
- Thêm role bạn muốn (ví dụ:
user
,admin
). - Cấu hình quyền cho từng hành động (Select, Insert, Update, Delete).
Ví dụ với bảng articles
:
- Role
user
:- Select: Chỉ đọc các bài viết có
is_published = true
. - Insert: Chỉ được thêm bài viết mới, nhưng author_id phải trùng với
X-Hasura-User-Id
. - Update: Chỉ được cập nhật bài viết của chính mình.
- Select: Chỉ đọc các bài viết có
- Role
admin
:- Có toàn quyền với tất cả dữ liệu.
Trong thực tế thì có nhiều hơn 1 quyền tuỳ thuộc vào ứng dụng của bạn như:
- Anonymous: cho phép xem những bài viết được public.
- User (đã đăng nhập): có thể tạo và chỉnh sửa thông tin bài viết của mình.
- Admin: toàn quyền với hệ thống.
- ....
4.3. Ưu điểm và hạn chế
Ưu điểm:
- Row-level & Column-level security: Bảo mật chi tiết đến từng bản ghi và cột.
- Dễ dàng cấu hình: Giao diện trực quan trên Hasura Console.
- Tích hợp với JWT: Dễ dàng kết hợp với các hệ thống auth phổ biến.
- Tự động đồng bộ: Khi thay đổi schema, permission cũng được cập nhật tương ứng.
Hạn chế:
- Phức tạp khi ứng dụng lớn: Nếu có nhiều bảng và nhiều role, việc quản lý rule sẽ khó khăn.
- Phụ thuộc vào Hasura Console: Dễ bị rối nếu không quản lý metadata bằng file hoặc GitOps.
- Tính năng nâng cao giới hạn: So với việc tự viết backend, một số logic phân quyền phức tạp phức tạp khó biểu đạt bằng rule của Hasura.
Kết luận
Tóm lại với những ứng dụng cần phát triển nhanh, không yêu cầu việc phân quyền quá phức tạp thì Permission trong Hasura
là một tính năng cực kỳ mạnh mẽ, giúp developer giảm tải việc viết code backend mà vẫn đảm bảo hệ thống an toàn, dễ quản lý.
Còn với những dự án có phân quyền phức tạp cần kết hợp với backend để đảm bảo vấn đề bảo mật.
Tài liệu tham khảo: Hasura Docs - Authorization