2.4.1. Bài toán phân quyền
Trong một hệ thống nhiều tính năng, nhiều người dùng và có thể lập trình được thì phân quyền là một bài toán phức tạp. Bài toán này đòi hỏi các yêu cầu sau:
1. Phân quyền chi tiết cho người dùng trên các module chức năng với các thao tác khác nhau, trên các phân nhóm dữ liệu khác nhau.
2. Đảm bảo tính hiệu quả (về tốc độ, bộ nhớ, …). 3. Dễ quản lý.
4. An toàn.
2.4.1.1. Phân quyền chức năng
Đặc điểm:
1. Hệ thống bao gồm nhiều gói, mỗi gói gồm nhiều module 2. Một module thường cho phép người dùng những khả năng sau:
o Xem danh sách, xem chi tiết, Thêm, sửa, xóa, quản trị 3. Một quyền bao gồm nhiều khả năng cho module
4. Tài khoản được phân các quyền
5. Tài khoản là một định danh được gắn với những khả năng hay cấu hình trong hệ thống.
6. Hệ thống gồm các loại tài khoản:
o USER: tài khoản của người dùng o PORTAL: tài khoản của cổng thông tin o GROUP: tài khoản của nhóm người dùng
7. Việc phân quyền quá chi tiết sẽ dẫn đến hệ thống phải thực hiện quá nhiều xử lý tốn kém tài nguyên hệ thống.
2.4.1.2. Phân quyền nội dung
Ngoài việc phân quyền theo chức năng còn đòi hỏi bài toán phân quyền theo dữ liệu hoặc loại dữ liệu.
1. Phân quyền theo loại dữ liệu:
Ví dụ: Một phóng viên chỉ được biên tập mục ―Thể thao‖, một phóng viên khác phụ trách mục ―Xã hội‖
Hệ thống gồm rất nhiều loại nội dung nên để tiện quản lý, các loại nội dung khác nhau được phân loại bằng một cây phân loại chung toàn hệ thống.
Một vấn đề nảy sinh do việc phân loại của các portal khác nhau:
Cách phân loại không giống nhau
Cần duy trì sự liên quan giữa các loại nội dung của các portal khác nhau. Ví dụ gian hàng A và B cùng bán điện thoại di động.
Do vậy cần 2 bảng phân loại nội dung: Một bảng là cây phân loại ―chuẩn‖ của toàn hệ thống, một là cây phân loại riêng của từng doanh nghiệp. Cây phân loại riêng ánh xạ vào cây chuẩn.
Việc phân quyền thực hiện trên cây phân loại riêng. Người dùng được phân quyền theo các danh mục phân loại.
2. Phân quyền theo nội dung:
Tương tự như phân quyền theo loại dữ liệu, bài toán phân quyền theo nội dung cũng dẫn đến việc thiết kế một bảng nội dung chung. Các loại nội dung cơ bản là:
1. NEWS: Tin tức. 2. PHOTO: Ảnh.
3. INTRODUCTION: Giới thiệu. 4. FAQ: Câu hỏi thường gặp. 5. LINK: Liên kết.
6. FORUM: diễn đàn. 7. DOCUMENT: Tài liệu.
8. RECRUIT: Thông tin tuyển dụng. 9. PRODUCT: Sản phẩm.
10.ADVERTISEMENT: Quảng cáo. 11.C2C: Rao vặt.
12.DIRECTORY: Thư mục. 13.FILE: file.
2.4.2. Vấn đề cơ sở dữ liệu
Hệ thống có nhiều loại đối tượng sử dụng: phân quyền, cấu hình hóa cá nhân phức tạp. Người dùng hay nhóm người dùng hay portal đều cần phân quyền và cấu hình hóa. Vậy làm sao để đơn giản hóa và đồng bộ hóa các công việc trên?
Hệ thống có nhiều loại nội dung: tin tức, sản phẩm, ảnh, phim, nhạc, tài liệu, … Nếu thiết kế database theo cách thông thường sẽ phải dùng rất nhiều bảng và việc phát triển hệ thống cho một loạt các bảng đó sẽ rất tốn kém và mất nhiều thời gian. Ngoài ra còn phải xây dựng nhiều module chức năng cho từng loại nội dung. Trên thực tế các loại nội dung đều … khá giống nhau, đều có: tên, mô tả, ảnh đại diện, mã số, phân quyền cho ai, ai là người tạo ra, ai comment ghi chú cái gì, …
Tương tự, có nhiều loại giao dịch, nhiều loại nhiệm vụ, khách hàng, … nếu thiết kế tổng quát có thể giảm được sự phức tạp của hệ thống, tăng tính linh hoạt và khả năng mở rộng, …
Vì những lý do trên chúng tôi đã sử dụng mô hình supertype trong một số thiết kế. Ví dụ bảng content có:
Trường type để phân biệt loại nội dung
Các trường cơ bản của một nội dung: tên, ảnh đại diện, mô tả, …
Trường meta để lưu các thông tin phụ ít quan trọng của nội dung
Bảng content_related để lưu quan hệ giữa các bảng
Bảng content_privilege để lưu phân quyền cho các tài khoản
Bảng content_type_field để lưu thiết kế các trường của từng loại nội dung Sơ đồ tổng quan:
Hình 14: Sơ đồ tổng quan mô hình supertype Ví dụ:
Hình 15: Ví dụ ứng dụng supertype Tuy nhiên khi sử dụng supertype thì gặp phải 2 vấn đề:
1. Do lưu trữ tập trung nên dẫn đến dư thừa dữ liệu 2. Gộp nhiều bảng lại làm kích thước một bảng tăng lên
Các thiết kế cơ sở dữ liệu dựa rất nhiều trên các mẫu analysis pattern của Martin Fowler. Tiêu biểu là:
Party [23]:
Party đại diện cho khách hàng, đối tác, nhân viên, … nghĩa là một đối tượng có tên, thông tin liên hệ, … sử dụng trong các tính năng của phần mềm SaaS.
Sơ đồ:
Accountability[23]:
Ứng dụng trong phân quyền. Đây là mẫu phân vai trò trách nhiệm cho các party.
Hình 17: Sơ đồ pattern Accountability
Transaction[23]
Thiết kế và lưu trữ các giao dịch. Sơ đồ:
Hình 18: Sơ đồ pattern Transaction
Account và Summary Account[23]:
Lưu các tài khoản kế toán. Sơ đồ:
Hình 19: Sơ đồ pattern Summary Account
Action[23]
Hình 20: Sơ đồ pattern Action
Hình 21: Sơ đồ pattern Plan
2.4.3. Vấn đề an toàn bảo mật
Đối với một hệ thống nhiều người dùng và nhiều tính năng, tương tác nhiều chiều thì bảo mật là một bài toán quan trọng và phức tạp.
Bài toán bảo mật càng phức tạp hơn do các yếu tố sau:
1. Cơ sở dữ liệu dùng chung: Dễ sử dụng tính năng của portal này tác động vào portal khác.
2. Cho phép người dùng phát triển code SaaS: Người dùng có thể viết các đoạn mã nguy hiểm tấn công hệ thống.
Để giải quyết bài toán bảo mật, ngoài việc ngăn chặn các lỗ hổng trong lập trình web thông thường cần:
Cho phép lưu trữ cơ sở dữ liệu phân tán để đảm bảo an toàn cho các dữ liệu . Quan trọng (nằm ở server khác và hạn chế truy cập).
Code SaaS chủ yếu chạy ở máy khách, sử dụng ngôn ngữ javascript. Các truy vấn tới database và hệ thống file được thực hiện bằng ajax qua các hệ thống trung gian.
Chương 3 PHÂN TÍCH HỆ THỐNG