Cảm ơn bạn nhé

Bài viết rất hay. Mô tả tốt các cách phân quyền thường dùng.

bài viết này của mình để làm việc đấy mà bạn

This is a tutorial to help you learn laravel. An effective way to learn. You should follow through each part of tutorial instead of asking for its source code

Cảm ơn bạn mình đang cố gắng viết nhiều bài như này để giúp cho mọi người nhiều hơn nữa

bài viết rất hay ạ. mong tác giả viết thêm nhiều bài về design database là một trong những chỗ mà mình thấy ngứa nhất (thực ra là mình thấy khó) : (((

Nếu được thì bạn so sánh giúp mình xem sao nhé, mình cũng tò mò muốn biết nó như thế nào . Cơ mà chỉ có haproxy là loadbalancer thôi nhé. Keepalived nó chỉ là service đi kèm tạo nên bộ đôi HA thôi. Keepalived cũng kèm với nginx được nha bạn.

ok bác, bình thường trên công ty vẫn dùng nginx, thấy khá ngon, để thử thêm keepalived-hapory xem sao

Sorry bạn, mình thật sự không biết giữa 2 loại loadbalancer này thì loại nào tốt hơn cả Tùy xem bạn handle cái nào được tốt hơn, control được nhiều nhất có thể thì dùng loại đó thôi. Trăm hay không bằng tay quen mà

Viết tiếp đi bạn, bài viết hay quá

Tương tự thế thôi bạn, bản chất HAproxy nó sẽ forward theo protocol, thế nên ứng dụng vào đc nhiều loại service. Apache thì là http/https , còn vsftp bạn dùng protocol nào thì config theo protocol đó thôi

Bạn có thể xem thêm về cách phân quyền ở git của bạn trên cung cấp cho chúng ta tham khảo: https://github.com/signes-pl/laravel-acl

Còn theo ý kiến cá nhân của mình bạn có thể gộp 2 loại này vào 1 bảng để check. Nhưng nếu bạn bạn đã làm quản lý theo 2 loại quyền tách biệt đó rồi thì mình thấy bạn nên viết 1 hàm để sử lý trường hợp này. tránh việc khi gom thành 1 bảng sẽ bị trồng quyền bằng cách tạo 1 function kiểu như này:

def check_logic user_child, action
  if user_child is member of self.user
   check_action action, self.user.role   (check true/false)
  end
  return false
end

def check_action action, role
  select ... from tbl_... where action = '+ 'action' +' and role = '+role+'
end

Vì nếu bạn để khi gộp lại quyền thì khổ nhất là công đoạn check quyền bạn sẽ phải sử dụng nhiều join và sub querry. Từ đó request sẽ lâu hơn khổ hơn khi sinh ra quyền mới. Nên mình thấy bạn phân ra làm 2 loại check là hợp lý. Nhưng hợp nếu đc hãy tạo thêm 1 table trung gian và có nhiều quyền trong đó hơn. khi đó user chỉ cần tạo quan hệ với bảng đó.

Nếu tính ra tbl_permission_grop có m row

tbl_permission_action có n row

=> bản chung gian chỉ cao nhất là m*n row.

Còn bảng chung gian giữa user và tbl_group_permission_action thì có tối thiểu m*n row. Và chỉ cần 3 join là lấy được quyền.

select ... from tbl_user 
   join tbl_group_permission_action
   join tbl_permission_grop
   join tbl_permission_action
   where action = ... and user = ...

Đó là quan điểm của mình trên những gì bạn đã làm. Nếu bạn đã làm gần ra sản phẩm thì nên cho nó debut trước. sau đó sẽ thấy nhiều vấn đề lúc này đập đi làm lại hẵng hay.

Bootstrap 4 không khác gì 3 mà bạn. Thêm nữa, trước đó mình viết seri về bootstrap 3 nên tiếp tục về nó. Sau này sẽ có bài về bootstrap 4 nhé

Sao bạn k hướng dẫn về boostrap 4 á?

Bài viết rất hay, cảm ơn bạn.

Mình đang có bài toán trên hệ thống của mình như sau và chưa biết nên xây dựng theo kiểu nào thì hợp lý. Đã có vài cách rồi nhưng vẫn chưa đc hợp lý lắm.

1. Phân quyền theo group,

Ví dụ

• Role Giám đốc có thể xem thông tin toàn bộ nhân viên
• Role Trưởng phòng xem thông tin toàn bộ nhân viên cấp dưới trưởng phòng
• Role Trưởng nhóm xem thông tin toàn bộ nhân viên caaso dưới của trưởng nhóm nhóm
• => Chỉ được xem thông tin của mình và toàn bộ nhân viên cấp dưới

2. Phân quyền theo Module hệ thống

Role hoặc cá nhân 1 người nào đó có thể Xem, Sửa, Xóa hoặc Export trên 1 module nào đó, trên 1 field nào đó của module đó

Ví dụ Trưởng phòng được xem thông tin của nhân viên cấp dưới mình, và chỉ được xem không được sửa.

Trưởng nhóm chỉ được xem thông tin nhân viên cấp dưới mình và không được xem field "Lương" của module đó.

Hiện tại mình đang tách ra riêng thành 2 hệ thống phân quyền.

1 là quản lý theo role

2 là module và field

Bạn có thể cho ý kiến được không nhỉ.

Bài viết hay. Cảm ơn tác giả.

Cám ơn bạn đã chia sẽ những kiến thức, tuy nhiên chỉ mới đọc đến đoạn đầu định nghĩa về closure mình đã thấy khó hiểu rồi, mình xin được trích dẫn lại :

Closure là những function tham chiếu đến các biến tự do (free avariable) tách biệt. Nói cách khác, function được định nghĩa trong closure sẽ ghi nhớ môi trường (environment) trong nó được tạo ra.

Closure là những function .... xong sau đó lại ... function được định nghĩa trong closure ... ?????

Nhờ bạn giải thích giùm mình đoạn này, mình thấy rối quá !

@thangtd90 Mình hiểu rồi, cám ơn bạn đã nhiệt tình giúp mình ạ

@wiliamfeng $(element).each() với $.each() thì không có gì khác biệt về chức năng (bởi 1 hàm thực chất là gọi đến hàm kia), tuy nhiên .forEach() thì hơi khác biệt một chút.

.forEach() là một hàm của Array.prototype, nên chỉ dùng được với array, không dùng được với object.

Tuyên nhiên $(element).each() với $.each() thì dùng được với cả object nữa. Bạn có thể check qua source code ở đây

Ở trên, bạn lấy ví dụ là var list = ['a','b','c','d']; tức với 1 array, nên cả 3 hàm đều trả ra kết quả giống nhau.

Nhưng khi list của bạn là một object jQuery, như var list = $('a') chẳng hạn, thì bạn chỉ có thể dùng list.each() với $.each(list, function() {}) thôi

Cảm ơn bạn đã đọc bài viết của mình