Công cụ dành cho nhà phát triển · Trình tạo UUID
Điều gì tạo nên một chuỗi UUID được hình thành tốt và điều mà người kiểm tra không thể biết
· Cách thức hoạt động
uuid mật mã browser-apis
Chữ hoa, dấu ngoặc nhọn, urn: tiền tố và dấu gạch nối bị thiếu đều xuất hiện trong đầu vào thực. Bài đăng này xác định dạng chuẩn, cho thấy những gì một trình xác thực khoan dung nên chấp nhận và tách biệt tính đúng đắn khỏi sự tồn tại.
400 lẽ ra phải là 404 — việc xác thực UUID cẩu thả tạo ra các lỗi API khó hiểu như thế nào
Điểm cuối API nhận giá trị nhận dạng từ ứng dụng khách: {12345678-90AB-CDEF-1234-567890ABCDEF}. Mã xác thực sẽ kiểm tra xem nó có khớp với /[0-9a-f]{32}/ hay không và từ chối vì coi nó không hợp lệ. Khách hàng nhận được 400 Yêu cầu không hợp lệ trong đó có nghĩa là 404 Không tìm thấy. Giá trị nhận dạng được định dạng đúng—nó là UUID hợp lệ ở định dạng có dấu ngoặc nhọn—nhưng trình xác thực quá nghiêm ngặt. Ngược lại, điểm cuối chấp nhận bất kỳ chuỗi thập lục phân 32 ký tự nào (không có dấu gạch ngang) sẽ chấp nhận 123456789012345678901234567890123456, phân tích cú pháp là hợp lệ và bỏ lỡ lỗi đánh máy. RFC 9562 xác định cách trình bày văn bản chuẩn nhưng thông tin đầu vào trong thế giới thực có năm định dạng khác nhau và trình xác thực chỉ chấp nhận dạng chuẩn sẽ từ chối 1 đến 5 phần trăm thông tin đầu vào có chủ đích.
Dạng văn bản chuẩn — 32 chữ số thập lục phân viết thường trong 8-4-4-4-12, chính xác là 36 ký tự, như tiêu chuẩn chỉ định cho đầu ra
Dạng văn bản chuẩn là 32 chữ số thập lục phân viết thường trong năm nhóm được phân tách bằng dấu gạch ngang: 8-4-4-4-12. Được biểu thị là 550e8400-e29b-41d4-a716-446655440000. Tiêu chuẩn bắt buộc viết thường cho đầu ra; về đầu vào, nên kết hợp không phân biệt chữ hoa chữ thường. Biểu mẫu này không rõ ràng, phân tích thành byte theo cùng một cách trên mọi nền tảng và là kết quả mà mọi thư viện UUID xuất ra theo mặc định. Nếu bạn đang tạo UUID mới từ CSPRNG, thì dạng chuẩn là những gì bạn nên tạo và những gì ToolAcre tạo ra. Đầu vào trong thế giới thực sai lệch theo những cách có thể dự đoán được. Số nhận dạng chữ hoa (550E8400-E29B-41D4-A716-446655440000) phổ biến trong các hệ thống mặc định là chữ hoa; chúng đại diện cho cùng một byte và phải được chấp nhận sau khi chuẩn hóa thành chữ thường.
Các biến thể bạn sẽ gặp trong tự nhiên — hex viết hoa, {braces}, tiền tố urn:uuid: và dạng không có dấu nối 32 ký tự và tiêu chuẩn cho biết phải chấp nhận
Biểu mẫu giằng ({550e8400-e29b-41d4-a716-446655440000}) là đầu ra tiêu chuẩn từ mô-đun uuid của Python và các hệ thống của Microsoft; tước niềng răng cho hình thức kinh điển hợp lệ. Tiền tố URN (urn:uuid:550e8400-e29b-41d4-a716-446655440000) được xác định bởi RFC 8141 cho tên tài nguyên thống nhất; loại bỏ lược đồ và loại bỏ tiền tố nhận dạng để lại dạng chuẩn. Dạng không có dấu gạch nối (550e8400e29b41d4a716446655440000) là 32 chữ số thập lục phân không có cấu trúc; đó là byte hợp lệ nhưng mất nhóm 8-4-4-4-12 nhóm giúp các phiên bản và biến thể có thể đọc được. Tất cả các biến thể này đều ánh xạ tới cùng một giá trị 128-bit. RFC 9562 phần 3 nêu rõ rằng trên đầu vào, các biến thể viết hoa SHOULD được chấp nhận. Nó không cấm các biến thể khác; nó nói rằng trên đầu ra, dạng chữ thường chính tắc MUST sẽ được sử dụng.
Độ chính xác của phiên bản và biến thể — có nên từ chối UUID có nhóm thứ ba bắt đầu bằng 0 hay nhóm thứ tư bắt đầu bằng f
Trình xác thực hợp lệ phải: chấp nhận biểu mẫu 8-4-4-4-12 chuẩn bằng chữ thường hoặc chữ hoa; chấp nhận các biến thể giằng và urn: bằng cách loại bỏ chúng và xác nhận dạng cốt lõi; chấp nhận chuỗi hex không có dấu gạch nối 32 chữ số và định dạng chúng dưới dạng chuẩn để so sánh; từ chối các chuỗi có số chữ số thập lục phân hoặc ký tự không thập lục phân không đúng. Lỗi phổ biến nhất là từ chối đầu vào viết hoa hoặc có dấu ngoặc nhọn vì trình xác nhận được viết bằng tay chỉ để khớp với dạng chuẩn. Việc kiểm tra độ chính xác của phiên bản và biến thể có thể phát hiện lỗi chính tả. Nếu nhóm thứ ba bắt đầu bằng 0 hoặc 9 thì UUID không hợp lệ hoặc được bảo lưu; nếu nhóm thứ tư bắt đầu bằng e hoặc f thì biến thể không phải là RFC 9562.
Ví dụ đã hoạt động - sáu chuỗi ứng viên trải qua quá trình kiểm tra nghiêm ngặt và một chuỗi nhẹ nhàng, kèm theo lý do mỗi chuỗi vượt qua hoặc thất bại
Trình xác thực khoan dung chấp nhận các giá trị này; một người xác nhận nghiêm ngặt có thể từ chối chúng. Kiểm tra ToolAcre được định dạng đúng sẽ thực hiện xác thực nghiêm ngặt: nó xác nhận dạng ký tự 36 chuẩn với dấu gạch ngang ở đúng vị trí, xác minh các chữ số thập lục phân ở mọi vị trí và kiểm tra xem phiên bản và các bit biến thể có nằm trong phạm vi hay không. Nó không kiểm tra xem UUID có tồn tại trong cơ sở dữ liệu của bạn hay nó được tạo từ một nguồn bảo mật bằng mật mã; đó là những kiểm tra riêng biệt được thực hiện bởi logic ứng dụng của bạn. Hình thức tốt không giống như thật. Chuỗi UUID phân tích cú pháp chính xác theo hình dạng của nó có thể không xác định được bất kỳ hàng nào trong cơ sở dữ liệu của bạn.
Được định dạng đúng là không có thật — tại sao UUID hoàn hảo về mặt cú pháp có thể không tồn tại trong dữ liệu của bạn và tại sao trình kiểm tra không bao giờ nên là lớp ủy quyền của bạn
MỘT UUID được hình thành hoàn hảo có thể đã bị đoán hoặc sao chép không chính xác. Xác thực định dạng là cổng đầu tiên; kiểm tra sự tồn tại và kiểm tra ủy quyền là thứ hai và thứ ba. Việc thực hiện tra cứu cơ sở dữ liệu cho mọi đầu vào không hợp lệ về định dạng là lãng phí; từ chối đầu vào có định dạng không hợp lệ trước khi truy vấn cơ sở dữ liệu giúp tiết kiệm thời gian. các ToolAcre Tiêu chuẩn đầu ra trình tạo 36-UUID ký tự; nếu bạn đang xây dựng trình xác thực của riêng mình, hãy chấp nhận các biến thể giằng và urn: để khớp với đầu vào trong thế giới thực và từ chối các chuỗi không tuân theo quy tắc hình dạng cơ bản trước khi hỏi cơ sở dữ liệu của bạn. Việc triển khai trình xác thực nghiêm ngặt yêu cầu các biểu thức chính quy và xử lý từng trường hợp. Hình thức kinh điển rất đơn giản: /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i (không phân biệt chữ hoa chữ thường). Biểu mẫu giằng thêm dấu ngoặc nhọn: /^\{[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\}$/i. Biến thể urn: thêm sơ đồ: /^urn:uuid:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i.
Điều này không bao gồm những gì - chuẩn hóa ID để lưu trữ và chọn loại cột, đây là những quyết định riêng biệt
Một biểu thức chính quy duy nhất xử lý tất cả các biến thể khó đọc hơn nhưng có thể. Hầu hết các trình xác thực đều chuẩn hóa trước: tách dấu ngoặc nhọn và tiền tố urn:, chuyển đổi thành chữ thường, sau đó khớp với mẫu chuẩn. Bạn có thể kiểm tra các bit phiên bản và biến thể sau khi khớp mẫu bằng cách kiểm tra vị trí 14 và vị trí 19 như được mô tả trong bài viết 403. Xử lý đầu vào không hợp lệ một cách khéo léo là một phần của thiết kế xác thực. Khi khách hàng gửi UUID không đúng định dạng, đừng để lộ mẫu biểu thức chính quy hoặc quy tắc xác thực nội bộ trong thông báo lỗi. Trả về lỗi rõ ràng: "Định dạng UUID không hợp lệ. Cần có định dạng 8-4-4-4-12, chẳng hạn như 550e8400-e29b-41d4-a716-446655440000." Đừng cố sửa đầu vào; yêu cầu khách hàng gửi lại.
Bài học rút ra: sớm xác thực hình dạng, tra cứu sự tồn tại riêng biệt — kiểm tra ToolAcre xác nhận hình dạng trong trình duyệt trước khi bạn chạm vào cơ sở dữ liệu
Một số hệ thống ghi lại thông tin đầu vào không hợp lệ để kiểm tra bảo mật (phát hiện các cuộc tấn công cố gắng chèn hoặc nhầm lẫn định dạng). Trình xác thực ToolAcre từ chối các biểu mẫu không chuẩn bằng thông báo lỗi rõ ràng và không cố gắng tự động sửa. Tại sao dạng chuẩn lại quan trọng đối với khả năng tương tác: nếu một hệ thống lưu trữ UUID dưới dạng hệ lục phân không gạch nối và một hệ thống khác lưu chúng dưới dạng chuẩn 8-4-4-4-12, thì việc so sánh chúng về sự bình đẳng đòi hỏi phải chuẩn hóa. Chữ hoa và chữ thường yêu cầu so sánh không phân biệt chữ hoa chữ thường. Niềng răng và trần đòi hỏi phải lột bỏ. Những biến thể này làm cho các hoạt động hàng loạt (nhập, di chuyển, so sánh) trở nên khó khăn hơn. Các công cụ tiêu chuẩn tạo ra dạng chuẩn giúp giảm ma sát. Trình tạo ToolAcre luôn xuất ra dạng chính tắc chữ thường có ký tự 36; khi bạn nhập UUID từ các hệ thống khác, hãy chuẩn hóa chúng thành biểu mẫu này trong quy trình ETL của bạn để đảm bảo tính nhất quán.