
Chấm dứt thảm họa if (role === 'admin'): Xây dựng cây phân quyền 3 cấp độ cho ứng dụng của bạn
Đừng để mã nguồn của bạn trở thành một mớ hỗn độn với hàng nghìn câu lệnh kiểm tra quyền truy cập rải rác. Bài viết này hướng dẫn bạn cách thiết kế hệ thống phân quyền 3 cấp độ chuyên nghiệp, giúp code sạch hơn, bảo mật hơn và dễ bảo trì hơn.
Bài viết được dịch và tổng hợp từ tin tức gốc. Bạn có thể đọc bài viết gốc bằng tiếng Anh tại đây.
Điểm tin nhanh:
- Loại bỏ tư duy kiểm tra quyền thủ công bằng if/else rải rác trong code.
- Thiết lập mô hình phân quyền 3 cấp độ: Page, Section và Action.
- Tối ưu hóa kiến trúc để dễ dàng mở rộng và bảo trì hệ thống.
Việc rải rác hàng trăm câu lệnh if (role === 'admin') khắp codebase không chỉ là một "cơn ác mộng" về bảo trì mà còn là lỗ hổng bảo mật tiềm tàng. Khi dự án của bạn mở rộng, việc quản lý quyền truy cập theo cách thủ công sẽ khiến quy trình phát triển trở nên chậm chạp và dễ xảy ra lỗi logic nghiêm trọng. Nếu bạn đang cảm thấy mệt mỏi với việc kiểm soát quyền truy cập, hãy cùng tìm hiểu giải pháp kiến trúc phân quyền 3 cấp độ dưới đây.
Tại sao cách tiếp cận cũ lại thất bại?
Khi ứng dụng còn nhỏ, việc kiểm tra quyền trực tiếp tại UI hoặc API endpoint có vẻ nhanh chóng. Tuy nhiên, khi đối mặt với các hệ thống phức tạp như Giải mã Visibility Modifiers trong Coluber, cách làm này sẽ tạo ra nợ kỹ thuật khổng lồ. Dưới đây là bảng so sánh giữa cách làm cũ và cách làm kiến trúc tập trung:
| Tiêu chí | Cách tiếp cận if/else rải rác | Kiến trúc phân quyền 3 cấp độ |
|---|---|---|
| Khả năng bảo trì | Rất thấp (cần sửa nhiều nơi) | Rất cao (sửa tại một nơi) |
| Tính bảo mật | Dễ bỏ sót (lỗi logic) | Chặt chẽ (tập trung tại middleware) |
| Khả năng mở rộng | Khó khăn | Dễ dàng thêm quyền mới |
| Độ phức tạp code | Cao (code bị phình to) | Thấp (code sạch, tách biệt) |

Thiết kế cây phân quyền 3 cấp độ
Để thoát khỏi bẫy Cái bẫy Overengineering, chúng ta cần một cấu trúc phân cấp rõ ràng. Hệ thống này chia quyền truy cập thành 3 tầng logic:
- Page Level: Kiểm soát quyền truy cập vào toàn bộ trang (ví dụ: chỉ Admin mới vào được trang Dashboard).
- Section Level: Kiểm soát các khối nội dung bên trong trang (ví dụ: chỉ Manager mới thấy được biểu đồ doanh thu).
- Action Level: Kiểm soát các hành động cụ thể (ví dụ: nút xóa, nút xuất dữ liệu).
Sơ đồ luồng xử lý quyền truy cập
[User Request] ---> [Middleware/Guard] ---> [Check Page Permission] ---> [Check Section Permission] ---> [Check Action Permission] ---> [Render UI/Execute API]
Mẹo hay: Hãy sử dụng các cấu trúc dữ liệu dạng cây (Tree structure) để lưu trữ quyền hạn, giúp việc tra cứu (lookup) trở nên nhanh chóng và hiệu quả hơn thay vì dùng các mảng phẳng.
Triển khai thực tế
Thay vì viết code cứng, hãy xây dựng một hệ thống dựa trên cấu hình (Configuration-based). Khi bạn xây dựng các ứng dụng phức tạp như Xây dựng hệ thống Electricity Planning Engine, việc tách biệt logic phân quyền giúp bạn tập trung vào core business thay vì loay hoay với các lỗi logic UI.
Lưu ý: Luôn đảm bảo rằng việc kiểm tra quyền không chỉ diễn ra ở phía Frontend mà phải được thực thi nghiêm ngặt ở phía Backend (API level). Frontend chỉ đóng vai trò hiển thị dựa trên quyền đã được xác thực.
Nếu bạn đang làm việc với các hệ thống yêu cầu bảo mật cao, hãy tham khảo thêm bài viết về Giải mã ATLOCK v4 để hiểu cách tự kiểm định kỹ thuật cho hệ thống của mình.
Đánh giá & Lời khuyên Thực tiễn
Ưu điểm:
- Codebase trở nên gọn gàng, dễ đọc.
- Dễ dàng thay đổi chính sách quyền mà không cần sửa hàng trăm file.
- Tăng tính bảo mật nhờ tập trung hóa logic kiểm tra.
Nhược điểm:
- Cần thời gian thiết kế ban đầu kỹ lưỡng.
- Yêu cầu team phải tuân thủ quy ước đặt tên và cấu trúc quyền.
Lời khuyên: Hãy bắt đầu bằng việc liệt kê tất cả các role hiện có và ánh xạ chúng vào 3 cấp độ trên. Đừng cố gắng làm quá phức tạp ngay từ đầu, hãy áp dụng nguyên tắc Thiết kế theo quan điểm để giữ hệ thống đơn giản nhất có thể.
Câu hỏi thường gặp (FAQ)
Tôi có nên dùng thư viện bên thứ ba không?
Có, nếu dự án của bạn lớn. Các thư viện như Casl hay AccessControl rất mạnh mẽ, nhưng nếu dự án nhỏ, tự xây dựng một hệ thống đơn giản vẫn tốt hơn.
Làm sao để xử lý quyền động (Dynamic Permissions)?
Bạn có thể lưu trữ cấu trúc quyền trong Database và load chúng vào bộ nhớ (caching) khi ứng dụng khởi chạy để đảm bảo hiệu năng.
Kiểm tra quyền ở Backend có làm chậm API không?
Nếu bạn tối ưu hóa việc truy vấn quyền (ví dụ: cache trong Redis), độ trễ sẽ là không đáng kể so với lợi ích bảo mật mang lại.
Kết luận
Việc từ bỏ thói quen sử dụng if (role === 'admin') là bước đi tất yếu để nâng tầm kỹ năng lập trình của bạn. Bằng cách thiết kế cây phân quyền 3 cấp độ, bạn không chỉ bảo vệ ứng dụng khỏi các lỗ hổng mà còn tạo ra một môi trường phát triển chuyên nghiệp, bền vững. Hãy bắt đầu refactor code của bạn ngay hôm nay và đừng quên theo dõi hi_dev để cập nhật thêm những kiến trúc phần mềm đỉnh cao khác.
Do you like this post?
Upvote to push this post higher on the community feed





