Có nên sử dụng UUID cho entity đã có field unique

Hi there,

Em thấy người ta thiết kế kiểu:

  • Entity account đã có field username là unique nhưng lại có thêm cột UUID làm gì vậy? cột UUID và cột username hợp thành primary key (app lại không có tính năng đổi username).
  • Entity sale order đã có saleOrderID nhưng vẫn có thêm field UUID để làm gì ạ?

thanks all!

không có gì gọi là nên hay không nên,
người ta làm như vậy vì có lý do, mục đích cụ thể
bạn có dùng hay không thì tuỳ bạn

để tránh lộ username / saleOrderID trong url của user/order đó. Lộ username thì tạo thuận lợi cho hacker tấn công brute force password. Nếu hacker ko biết username thì khó khăn hơn. Nên thay vì để link abc.com/user/someoneusername lúc copy paste bị lộ username, đổi lại thành abc.com/user/2389752938 với 1 con số ngẫu nhiên nào đó là người ta có copy paste link share user profile cho người khác cũng ko bị lộ username. Xài số lớn bao nhiêu cũng phải suy nghĩ: 32-bit tuy tới 4 tỷ số nhưng rất dễ trùng: chỉ cần random 50 ngàn giá trị thì có 25% chance là có 1 cặp trùng: https://en.wikipedia.org/wiki/Birthday_attack vì vậy người ta mới xài số lớn tới 128-bit luôn: tạo ngẫu nhiên 26 tỷ giá trị 128-bit thì xác suất 2 số trùng nhau chỉ có 10^-18, đó chính là uuid.

áp dụng cho sale order cũng tương tự nha :V tạo cái link abc.com/order/123 thì rất dễ bị người khác mò tiếp /order/124 xem order của người khác, thế là phải check có đúng user cho order này ko, buộc người ta phải login mới xem order được v.v… :V nên ẩn đi bằng cách tạo 1 số ngẫu nhiên 128-bit là khỏi mò, dev cũng khỏi cần rào trước đón sau kiểm tra user cẩn thận gì nữa :V, hoặc tạo thuận lợi cho việc share link tới order cho người khác xem

5 Likes

bạn đang dùng entity framework .net à

83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?