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

Cám ơn bạn ạ, vậy là nói chung 3 thằng này không có khác biệt nhau gì về chức năng đúng không ạ

1. Không nhé, nếu bạn muốn dùng mysql thì phải cài add-on khác. Mặc định thì chỉ dùng được pgsql thôi. Mà việc chuyển đổi CSDL giwuxa mysql và pgsql chắc không có khác biệt gì đâu vì Laravel lo liệu hết rồi
2. Bạn đang dùng Laravel phiên bảo bao nhiêu vậy ?

cảm động rơi cả nước mắt @nguyen.thi.huong

Theo mình nếu làm theo cách của này thì có vài chỗ sẽ bị quanh quẩn như kiểu bảng user vs group, user vs role. Dẫn đến sẽ khó hiểu cho những người mới đọc vì luồng dữ liệu không clear khi đọc lần đầu. Nếu mình làm thì mình sẽ đưa người dùng ra 1 phía vì bài toán phục vụ cho họ nên phần phân quyền ta tự quyết định với nhau xong cần 1 bảng user-role là được. Tất nhiên cách của bạn đưa ra họ đã tính đến vài trường hợp mà mình chưa gặp nên chắc họ làm vòng như thế là có lý do. Nếu bạn muốn chi tiết hơn có thể xem cách phân quyền của joomla nó cũng làm giống kiểu này nè Cảm ơn bạn đã bình luận và góp ý cho mình.

Anh ơi e hỏi:

• Trong file env của e dùng DB_CONNECTION=mysql thì có sài dc add-on Heroku Postgres không ạ?
• E chạy đến đoạn git push heroku master thì bị lỗi

thì phải làm sao ạ?

Cái thứ 3 thì có 1 packet có xài như sau: https://github.com/signes-pl/laravel-acl

Có vài điểm cảm thấy ko đúng như luồng suy nghĩ thông thường, nhưng xài thì vẫn tốt, cơ mà chưa kiếm được dự án đủ tầm để áp dụng.

tks bạn nhiều nhé