เครื่องมือสำหรับนักพัฒนา · ตัวสร้าง UUID
UUID ตามชื่อ (v3 และ v5): ID ที่กำหนดจากเนมสเปซ
· พื้นหลัง
uuid การเข้ารหัส เบราว์เซอร์-apis
เมื่อบันทึกภายนอกเดียวกันต้องได้รับตัวระบุเดียวกันเสมอ UUID แบบสุ่มจะไม่ได้รับ เวอร์ชัน 3 และ 5 UUIDs แฮชเนมสเปซและชื่อลงใน ID ที่เสถียร โพสต์นี้จะอธิบายวิธีและเวลาในการใช้งาน
การนำเข้าลูกค้ารายเดิมซ้ำสองครั้ง — ปัญหาการทำซ้ำที่ ID ที่กำหนดจะแก้ไขได้
ไปป์ไลน์การนำเข้าข้อมูลจะได้รับบันทึกลูกค้าจากระบบภายนอกโดยมี ID ภายนอกที่เสถียรภายในระบบนั้น หากคุณสร้าง UUID แบบสุ่มใหม่สำหรับการนำเข้าแต่ละครั้ง การนำเข้าลูกค้ารายเดียวกันสองครั้งจะสร้างตัวระบุที่แตกต่างกันสองตัวและบันทึกที่ซ้ำกัน ความซ้ำซ้อนนี้จะไหลไปสู่ระบบการรายงาน การเรียกเก็บเงิน และระบบสนับสนุน หากคุณได้รับ UUID จาก ID ภายนอกของลูกค้าและเนมสเปซที่เสถียรซึ่งเป็นตัวแทนของแหล่งนำเข้าของคุณ การนำเข้าทุกครั้งจะสร้าง UUID เดียวกันสำหรับลูกค้ารายเดียวกัน ทำให้คุณสามารถระบุและอัปเดตบันทึกที่มีอยู่ได้ ระดับนี้เป็นคุณลักษณะที่กำหนดของ UUID v3 และ v5: พวกมันไม่ได้สร้างขึ้นอย่างอิสระ แต่ได้มาจากอินพุต และอินพุตเดียวกันจะสร้าง UUID ที่เหมือนกันเสมอ
เนมสเปซบวกชื่อ — วิธีเชื่อมต่อและแฮชอินพุต และเหตุใดเนมสเปซจึงป้องกันการชนกันระหว่างแหล่งที่มาต่างๆ
v3 หรือ v5 UUID มาจากสามองค์ประกอบ: เนมสเปซ UUID (โดยทั่วไปกำหนดไว้ล่วงหน้า) ชื่อ (สตริงไบต์ใดๆ) และอัลกอริธึมแฮช (MD5 สำหรับ v3, SHA-1 สำหรับ v5) เชื่อมต่อ 16 bytes ของเนมสเปซ UUID กับ UTF-8 ไบต์ของชื่อ แฮชการต่อข้อมูล รับ 16 bytes แรกของเอาต์พุตแฮช และตีความไบต์เหล่านั้นเป็น UUID โดยตั้งค่าเวอร์ชัน nibble เป็น 3 หรือ 5. เนมสเปซแบ่งพาร์ติชันพื้นที่ ID: v5 UUID จากเนมสเปซ DNS ไม่เคยขัดแย้งกับ v5 UUID จากเนมสเปซ URL RFC 9562 กำหนดเนมสเปซที่กำหนดไว้ล่วงหน้าสี่รายการ: ตามชื่อ DNS โดย URL โดย OID และโดย X.500 ชื่อที่แตกต่าง องค์กรสามารถสร้างเนมสเปซของตนเองได้โดยการสร้าง v4 UUID
MD5 ใน v3 และ SHA-1 ใน v5 — เหตุใดแฮชที่อ่อนแอลงจึงเป็นที่ยอมรับได้ที่นี่ เนื่องจาก ID ไม่ใช่การควบคุมความปลอดภัย
เวอร์ชัน 3 ใช้ MD5 และเวอร์ชัน 5 ใช้ SHA-1 ตัวเลือกที่สืบเนื่องมาจากวันที่ข้อกำหนดและการใช้งานที่มีอยู่ สำหรับ UUID ตามชื่อ ความแตกต่างนี้ไม่สำคัญ เนื่องจากฟังก์ชันแฮชไม่ใช่ขอบเขตความปลอดภัยหรือการควบคุมการเข้ารหัส UUID ไม่ได้พิสูจน์ความถูกต้องหรือความสมบูรณ์ มันเป็นเพียงการแปลงสตริงที่มีความยาวผันแปรให้เป็นค่า 128- บิตคงที่ โมเดลการโจมตีไม่เกี่ยวข้องเนื่องจาก UUID ถูกจัดเก็บและเปรียบเทียบเป็นค่าทึบแสง ไม่ใช่เป็นการพิสูจน์หรือควบคุมความปลอดภัย การใช้งานใหม่ควรใช้ v5 (SHA-1) แทนที่จะเป็น v3 (MD5) ไม่ใช่ด้วยเหตุผลด้านความปลอดภัยที่น่าสนใจ แต่เนื่องจาก v5 เป็นมาตรฐานสมัยใหม่และมีอยู่อย่างกว้างขวาง
เนมสเปซที่กำหนดไว้ล่วงหน้า — DNS, URL, OID และ X.500 และเมื่อใดที่คุณควรสร้างเนมสเปซของคุณเอง
RFC 9562 ระบุ UUID เนมสเปซที่กำหนดไว้ล่วงหน้าสี่รายการพร้อมการแสดงไบต์เฉพาะ: 6ba7b810-9dad-11d1-80b4-00c04fd430c8 สำหรับ DNS, 6ba7b811-9dad-11d1-80b4-00c04fd430c8 สำหรับ URL, 6ba7b812-9dad-11d1-80b4-00c04fd430c8 สำหรับ OID และ 6ba7b814-9dad-11d1-80b4-00c04fd430c8 สำหรับ X.500 ชื่อที่แตกต่าง v5 UUID มาจากเนมสเปซ DNS และชื่อ www.example.com จะเหมือนกันเสมอและจะไม่ขัดแย้งกับ v5 UUID จากเนมสเปซ URL การใช้เนมสเปซที่กำหนดไว้ล่วงหน้าช่วยให้มั่นใจในการทำงานร่วมกัน: หากหลายทีมใช้ v5 อย่างอิสระกับเนมสเปซ DNS พวกเขาจะสร้าง UUID ที่เหมือนกันสำหรับชื่อ DNS เดียวกัน การเลือกหรือการสร้างเนมสเปซเป็นส่วนหนึ่งของการออกแบบสคีมา
ตัวอย่างการทำงาน - ได้รับ v5 UUID ตามแนวคิดจากเนมสเปซ URL และบันทึก URL ทีละขั้นตอน
รับ v5 UUID ตามแนวคิดจากเนมสเปซ URL และชื่อ https://example.com/api/users/42. เนมสเปซ UUID เป็น 16 bytes คือ 6b a7 b8 11 9d ad 11 d1 80 b4 00 c0 4f d4 30 c8 ชื่อคือสตริง UTF-8 https://example.com/api/users/42, ซึ่งก็คือ 30 bytes เชื่อมต่อเนมสเปซไบต์ (16) และไบต์ของชื่อ (30) เพื่อให้ได้ผลรวม 46 bytes คำนวณแฮช SHA-1 โดยสร้างแฮชขนาด 20 ไบต์ ใช้ 16 bytes ตัวแรกและตีความว่าเป็น UUID โดยตั้งค่าเวอร์ชัน nibble เป็น 5 และบิตตัวแปรตั้งค่าเป็น RFC มาตรฐาน การคำนวณอีกครั้งด้วยอินพุตที่เหมือนกันจะให้ผลลัพธ์ที่เหมือนกัน นักพัฒนาส่วนใหญ่ใช้ภาษา UUID ไลบรารี่เพื่อคำนวณ v5
รูปแบบจะแตกเมื่อใด - เมื่อเปลี่ยนชื่อ เมื่อเนมสเปซไม่สอดคล้องกันระหว่างทีม และเมื่ออินพุตเป็นความลับ
UUID ตามชื่อจะถือว่าชื่อมีความเสถียรและสม่ำเสมอทั่วทั้งระบบและการนำเข้า หากบันทึกภายนอกเดียวกันมีชื่อต่างกันในระบบที่แตกต่างกัน การสร้าง v5 จากแต่ละชื่อจะสร้าง UUID ที่แตกต่างกันและไม่สามารถระบุบุคคลคนเดียวกันได้ หากเนมสเปซไม่ได้รับการตกลงกันระหว่างทีม (แต่ละทีมสร้างเนมสเปซของตัวเองสำหรับสิ่งที่เป็นแหล่งที่มาเดียวกัน) พวกเขาจะสร้าง UUID ที่แตกต่างกันและไม่สามารถจับคู่บันทึกได้ หากอินพุตเป็นข้อมูลที่ละเอียดอ่อน การสร้าง v5 UUID หมายความว่า UUID เป็นค่าสาธารณะที่กำหนดขึ้นซึ่งใครๆ ก็สามารถค้นหาได้หากพวกเขาทราบอินพุต การกำหนดจะพังเมื่ออินพุตเปลี่ยนแปลงหรือคำจำกัดความของเนมสเปซไม่สอดคล้องกัน
สิ่งนี้ไม่ครอบคลุมถึง — ตัวสร้าง ToolAcre ดึงมาจาก CSPRNG ดังนั้น ID ตามชื่อจำเป็นต้องมีไลบรารี UUID ของภาษาของคุณ
ToolAcre สร้าง UUID v4 เท่านั้น ซึ่งดึงมาจากตัวสร้างที่ปลอดภัยด้วยการเข้ารหัสของเบราว์เซอร์เพื่อความเป็นอิสระ การสืบทอดตามชื่อ UUID ต้องใช้ไลบรารีภาษา UUID ของคุณ หรือการนำไปใช้ที่คำนวณ SHA-1 และจัดรูปแบบผลลัพธ์อย่างถูกต้อง โพสต์นี้จะอธิบายแนวคิดและกรณีการใช้งาน การใช้งานรุ่น v5 นั้นตรงไปตรงมาในทุกภาษาที่สามารถเข้าถึงไลบรารีการเข้ารหัสมาตรฐาน กลไกของการสืบทอด v5 นั้นเรียบง่าย ความท้าทายคือการบูรณาการเข้ากับสคีมาของระบบโดยที่เนมสเปซมีเสถียรภาพ ชื่อมีความสอดคล้อง และแนวทางนี้ได้รับการจัดทำเป็นเอกสารไว้อย่างดีสำหรับทีมของคุณ ทีมพัฒนาควรจัดทำเอกสารตัวเลือกเนมสเปซ
ประเด็นสำคัญ: กำหนดไว้เมื่อคุณต้องการ อย่างอื่นสุ่ม — ใช้ v5 สำหรับการแมปที่เสถียรและตัวสร้าง ToolAcre สำหรับทุกสิ่งที่ไม่ควรคาดเดา
ใช้ v5 สำหรับการแมปที่เสถียรระหว่างตัวระบุภายนอกและบันทึกภายในของคุณ ระดับนี้จะป้องกันการนำเข้าซ้ำซ้อน และทำให้บันทึกการจับคู่ระหว่างระบบตรงไปตรงมาและเชื่อถือได้ อย่าใช้ UUID ตามชื่อสำหรับตัวระบุที่ต้องคาดเดาไม่ได้หรือสำหรับสถานการณ์ที่ต้องใช้การรักษาความลับและความลับที่เข้มงวด ToolAcre สร้าง UUID v4 แบบสุ่มสำหรับตัวระบุที่ต้องเป็นอิสระและแตกต่างโดยไม่ต้องคาดเดาได้ เมื่อระบบของคุณต้องการ ID ที่กำหนดซึ่งแมปอินพุตกับตัวระบุคงที่ ไลบรารีภาษา UUID ของคุณจะสามารถคำนวณได้ ความมุ่งมั่นเป็นคุณสมบัติที่ทรงพลังเมื่อคุณควบคุมอินพุต