Bảo vệ nội dung¶

• Bảo vệ nội dung
• Mô tả
• Sử dụng
• Quan trọng
• Ứng dụng
• Thảo luận
• Vấn đề
• Hiện tại
• Ý tưởng

Mô tả¶

Nội dung của một bài viết bất kỳ ở trang web của Freebox có thể được bảo vệ bằng cách sử dụng chỉ thị về quyền. Nhờ đó, việc đọc nội dung của bài viết được cho phép / từ chối đối với các thành viên hay nhóm thành viên nhất định. Cách bảo vệ nội dung đi kèm với sự phân quyền tạo ra các phân lớp đọc - ghi rất rộng.

Khi một người dùng truy cập mội trang nội dung bị cấm, họ chỉ nhìn thấy thông báo Contents protected.

Chỉ thị quyền cũng ngăn không cho phép nội dung của bài viết bị lộ qua các email khi người dùng bất kỳ chọn Theo dõi chủ đề nào đó.

Sử dụng¶

Chú ý: Ta sử dụng người dùng để chỉ bất kỳ những người có đăng ký tại trang Freebox, và thành viên để chỉ rằng người dùng đó có tham gia một dự án cụ thể. Về các quyền (hay vai trò, hay nhóm thành viên) đối với người dùng đối với từng dự án, xem thêm ở User Roles.

Để bảo vệ một bài viết, ngay đầu bài viết đó, cần chèn vào chuỗi {{{...}}} (vị trí của các dấu chấm sẽ thay thế bằng các chỉ thị). Một chỉ thị thuộc một trong các dạng sau:

Chỉ thị	Ý nghĩa
allow @all	Cho phép đối với tất cả thành viên
allow @Blogger	Cho phép đối với thành viên có quyền là @Blogger. (Xem thêm User Roles.)
allow abc	Cho phép thành viên có nick là abc
allow ~zzz	Cho phép thành viên có id là zzz
deny @all	Từ chối đối với mọi thành viên, trừ người điều hành @Manager
deny xyz	Từ chối đối với thành viên có nick là xyz
deny ~zzz	Từ chối phép thành viên có id là zzz
nomail	Khi bài viết được tạo ra, không gửi mail thông báo đến người dùng

Các nhóm thành viên và có nick của thành viên có thể được liệt kê cách nhau bởi dấu phảy, trong khi các chỉ thị cách nhau bởi dấu chấm phẩy. Ngoài ra, chỉ thị được liệt kê sau sẽ có tác dụng đè đối với chỉ thị đi trước.

Dưới đây là các ví dụ minh họa, đối với một bài viết cụ thể

Chuỗi	Được xem nội dung bài viết	Không được xem nội dung bài viết
{{{}}}	Người điều hành dự án	Tất cả các thành viên, trừ người điều hành
{{{nomail}}}	Người điều hành dự án	Tất cả thành viên, trừ người điều hành
	Khi tạo bài viết, không gửi mail thông báo
{{{allow @all}}}	Tất cả thành viên dự án	Người dùng không là thành viên dự án
{{{allow @Blogger,tanphu}}}	Người điều hành dự án	Tất cả các thành viên còn lại
	Thành viên với quyền @Blogger
	Thành viên có nick là tanphu
{{{allow @all; deny tanphu}}}	Mọi thành viên của dự án, trừ tanphu	Người dùng có nick là tanphu
{{{deny tanphu; allow @all}}}	Tất cả thành viên của dự án	Người dùng không phải là thành viên
{{{all @all;nomail}}}	Tất cả thành viên của dự án	Người dùng không phải là thành viên
	Khi bài viết được tạo ra, sẽ không gửi mail thông báo
{{{deny abc,xyz}}}	Người điều hành dự án	Tất cả người dùng

Quan trọng¶

1. Người điều hành dự án có quyền đọc bất kỳ bài viết nào trong dự án, ngay cả khi bạn chỉ ra {{{deny @Manager}}}. Lưu ý là, người quản trị trang web không hẳn thuộc vào nhóm người điều hành của dự án cụ thể, do đó, đôi khi ngay cả người điều hành trang web cũng không thể đọc được nội dung bài viết
2. Nếu một thành viên không được phép xem một bài viết, tất nhiên các email thông báo sẽ không được gửi đến người đó khi bài viết được tạo ra
3. Việc dùng đúng số lượng các dấu ngoặc rất quan trọng, nghĩa là {{{...}}} là hợp lệ, nhưng {{...}}} (thiếu dấu { mở đầu) hoặc {{{...}} (thiếu } kết thúc) đều không hợp lệ. Ngoài ra, ba ký tự {{{ phải bắt đầu nội dung bài viết, theo nghĩa, không được phép có bất kỳ ký tự nào trước {{{ (kể cả ký tự trắng).
4. Bên trong cặp {{{ và }}}, có thể chứa tùy ý các khoảng trắng, kể cả dấu xuống dòng. Tuy nhiên, chiều dài từ ký tự { đầu tiên cho đến ký tự } cuối cùng không được vượt quá 103 ký tự.
5. Khi dùng chỉ thị quyền, bạn cần nhớ thêm quyền cho chính bạn.
   • Ví dụ, nếu bạn có nick là abcxyz, thì bạn cần sử dụng, chẳng hạn {{{deny @all;all @Blogger; allow abcxyz}}}
   • Bởi nếu không dùng như vậy, bạn sẽ không thể đọc được nội dung bài viết cho chính bạn tạo ra
     • Trong trường hợp bạn có quyền sửa bài viết cho chính mình tạo ra, thì không vấn đề gì, vì bạn có cơ hội để điều chỉnh.
     • Nhưng một số thiết lập chỉ cho phép bạn gửi bài viết mà không được sửa, và khi đó bạn phải liên lạc với người điều hành để chỉnh lại bài giúp bạn
6. Chỉ phần nội dung bài viết được bảo vệ, còn chủ đề hay tựa đề bài viết thì không. Do đó, hãy cẩn thận. Nếu có bảo vệ nội dung thì bạn cần chọn một tiêu đề thích hợp để nó không giúp cho người khác đoán được toàn bộ điều bạn muốn trình bày. Tất nhiên, cách chọn chủ đề phải phù hợp, như mô tả ở Smart Questions.
7. Việc chỉ ra {{{allow @all}}} không có nghĩa là bất kỳ ai cũng đọc được nội dung. Chỉ thị đó có nghĩa chính xác là: tất cả các thành viên của dự án có thể xem nội dung bài viết. Việc dùng {{{allow @all}}} có ý nghĩa đối với dự án công cộng.
8. Lưu ý đặc biệt tới chỉ thị {{{allow @all; deny xyz}}} trong trường hợp dự án là công cộng. Dụng ý của chỉ thị đó là cho phép mọi thành viên của dự án, trừ thành viên xyz, đọc được thông tin bài viết. Tuy nhiên, vì dự án là công cộng, nên thành viên đó có thể đăng ký một tài khoản khác ví dụ là xyzt, tham gia vào dự án (vào nhóm User) và hiển nhiên đọc được nội dung bài viết, bởi vì xyzt không bị cấm bởi chỉ thị đó. Nói chung, kiểu chỉ thị {{{allow @all; deny xyz}}} cần nên tránh, thay thế bởi việc phân ra các nhóm khác nhau và đặt chỉ thị cho nhóm. Ví dụ, {{{allow @Blogger; deny xyz}}} (nếu thành viên xyz thuộc vào nhóm Blogger). Còn khi muốn từ chối một thành viên trong nhóm User, cách tốt nhất là từ chối mọi thành viên của nhóm User đó.
9. Chỉ thị được liệt kê sau sẽ có tác dụng đè đối với chỉ thị đi trước. Ví dụ, nếu thành viên xyz thuộc vào hai nhóm Blogger và User, thì việc cài đặt {{{allow @Blogger, @User; deny xyz}}} sẽ ngăn thành viên xyz tiếp cận nội dung bài viết. Lý do là chỉ thị nêu ra sau cùng deny xyz xác nhận việc từ chối, bất kể thành viên xyz có thuộc vào các nhóm được phép đọc đã chỉ ra trước đó (Blogger và User).
10. Nếu không để ý quy tắc vừa nói ở trên, bạn có thể làm lộ các nội dung mà bạn muốn bảo vệ, hoặc bạn có thể không đọc được bài viết mà bạn là tác giả

Ứng dụng¶

Dưới đây là các ứng dụng cơ bản của chỉ thị quyền

1. Hạn chế quyền truy cập đối với các nội dung nhất định
2. Gửi các thông tin riêng tư đến thành viên khác
3. Hạn chế gửi mail đến các thành viên
4. Thực hiện các trao đổi riêng tư đối trong một luồng bài viết bất kỳ

Thảo luận¶

Việc triển khai khả năng bảo vệ bài viết như trên cần được thảo luận. Vui lòng đặt vấn đề mới tại dự án Rocky.

Vấn đề¶

1. Các hạn chế của allow @all
2. Việc cho phép người dùng sửa các bài viết có thể dẫn tới tình trạng sau: một bài viết do @Manager tạo ra và chỉ dành riêng cho họ, nhưng do nhóm @Moderator có quyền sửa bài viết, nhóm này có thể chọn Sửa để đọc nội dung bài này. Các hướng khắc phục
   • Bỏ luôn quyền sửa đối với các bài bị cấm đọc
   • Cho phép tác giả một bài viết sửa bài của chính họ, bỏ qua các chỉ thị
3. Khi chọn sửa trang wiki bị cấm đọc, nội dung bị cấm đọc sẽ chỉ hiện ra Contents protected, và ta vẫn cho phép người dùng sửa (sau này có thể phục hồi được.)
4. Khi sửa các nội dung cấm đọc khác, phải loại bỏ hoàn toàn quyền ghi (truy cập action = :edit sẽ bị lỗi), để tránh tình trạng nội dung bài viết bị mất
5. Tính năng đề nghị
   1. Tác giả luôn có quyền được (đọc và) sửa nội dung bài viết của chính mình
   2. Người biên tập nội dung có quyền sửa bài viết thuộc phạm vi của họ, bất kể bị cấm đọc
   3. Người biên tập nội dung chỉ có quyền sửa bài đối với các bài họ được phép sửa (quyền này được cấp phát riêng thông qua các chỉ thị hợp lý)
   4. Khi một bài không được đọc và bị hạn chế quyền ghi, cần phải hạn chế triệt để, tránh tình trạng thể hiện nội dung ở dạng foobar làm mất nội dung gốc

Hiện tại¶

Đối với các nội dung bị cấm, việc điều chỉnh sẽ dẫn tới các phản ứng khác nhau. Do việc thay đổi cần can thiệp sâu vào hệ thống lõi, nên phải phát triển dần dần hoặc tìm các giải pháp thay thế khác.

Nội dung	Nội dung thấy khi sửa	Kết quả điều chỉnh	Sự an toàn	TODO
Trang wiki	Contents protected	Phải phục hồi nội dung	An toàn, không sợ mất nội dung cần bảo vệ
Bình luận của vấn đề	Bản gốc	Người sửa quyết định	Lộ nội dung cho người sửa, an toàn đối với tác giả
Chi tiết của vấn đề	Bản gốc	Người sửa quyết định	Lộ nội dung cho người sửa, an toàn đối với tác giả
Bài viết ở diễn đàn	Bản gốc	Người sửa quyết định	Lộ nội dung cho người sửa, an toàn đối với tác giả
Tin tức, Blog	Bản gốc	Người sửa quyết định	Lộ nội dung cho người sửa, an toàn với tác giả

(Có sự khác biệt là do cách dùng lẫn lộn form_for và text_area_tag trong mã của Redmine. An toàn với tác giả có nghĩa là tác giả có cơ hội chỉnh lại bài viết và bổ sung thêm quyền để bản thân họ có thể xem được bài của chính mình.)

Ý tưởng¶

Ý tưởng về chỉ thị quyền (Page Permission hay Text Persmission) và mã Ruby thể hiện ý tưởng cho hệ thống Redmine thuộc quyền sở hữu của Kỳ Anh (tháng 12/2009).