บทความนี้แนะนำวิธีการใช้เครื่องมือที่มีอยู่ในการย้ายข้อมูลผู้ใช้ที่ผ่านมามายัง Logto ในสถานการณ์ที่ Logto ยังไม่ได้ให้บริการย้ายข้อมูล
Logto ยังไม่มีชุดเครื่องมือสำหรับการย้ายข้อมูล แต่เราได้เปิดความสามารถพื้นฐานของ Management API แล้ว ซึ่งจะไม่เป็นอุปสรรคต่อการที่ผู้ใช้ต้องการย้ายฐานข้อมูลผู้ใช้ที่มีอยู่โดยการเขียนสคริปต์
เมื่อพิจารณาถึงความต้องการบางอย่างที่ได้รับจากผู้ใช้ในชุมชนและข้อเท็จจริงที่ว่าเราในปัจจุบันยังไม่มีเอกสารที่อธิบายขั้นตอนเฉพาะของการย้ายฐานข้อมูลผู้ใช้ เราจึงทำการแนะนำอย่างเหมาะสมในบทความนี้เพื่อช่วยให้ผู้ใช้หาวิธีเฉพาะและประหยัดเวลาในการอ่านโค้ดและเอกสารของ Logto
Logto ใช้ ฐานข้อมูล PostgreSQL ใต้ระบบของมัน นอกจากข้อได้เปรียบด้านประสิทธิภาพหลากหลายแล้ว เหตุผลสำคัญคือมันสนับสนุนการสร้างประเภทข้อมูล JSON/JSONB ที่กำหนดเอง และอนุญาตให้สร้างการทำดัชนีบนค่าในตัวของข้อมูลประเภท JSON ทำให้สมดุลระหว่างประสิทธิภาพของฐานข้อมูลและความขยายตัว
สำหรับโครงสร้างข้อมูลผู้ใช้ของ Logto โปรดดูที่ user reference เพื่อทำความเข้าใจรายละเอียดทั้งหมด ที่นี่เราจะมุ่งเน้นในการอธิบายบางแง่มุมที่ Logto อาจแตกต่างจากบริการระบุตัวตนอื่น ๆ
นี่คือรหัสประจำตัวที่ไม่ซ้ำกันซึ่งถูกสร้างสุ่มสำหรับผู้ใช้ของ Logto ผู้ใช้จะไม่ทราบถึง id เมื่อใช้บริการพื้นฐานของ Logto
วิศวกรที่คุ้นเคยกับฐานข้อมูลไม่ควรพบว่ามันแปลก แม้แต่ระบบระบุตัวตนขั้นพื้นฐานที่สุดก็จะมี id เพื่อระบุตัวผู้ใช้เฉพาะ แม้ว่ารูปแบบของพวกเขามักจะต่างกัน บริการระบุตัวตนบางตัวอาจใช้ชื่อผู้ใช้เพื่อระบุตัวผู้ใช้เฉพาะ
ที่นี่ ชื่อผู้ใช้ อีเมลหลัก โทรศัพท์หลักเป็นที่ที่ Logto แตกต่างมากจากระบบระบุตัวตนอื่น ๆ ทั้งหมดนี้สามารถเป็นตัวระบุตัวผู้ใช้ที่สังเกตได้จากผู้ใช้ปลายทาง
ในระบบระบุตัวตนอื่น ๆ หลาย ๆ ระบบ ชื่อผู้ใช้จะถูกใช้เพื่อระบุตัวตน (ชื่อผู้ใช้ที่จะไม่ซ้ำกันระหว่างบัญชี) ซึ่งง่ายต่อการเข้าใจ
แต่ใน Logto อีเมลหลัก/โทรศัพท์หลักก็ใช้เพื่อแยกแยะผู้ใช้เช่นกัน นั่นคือ ถ้าผู้ใช้ A มีอีเมลหลัก [email protected] แล้ว ผู้ใช้ B อื่น ๆ จะไม่สามารถเพิ่มที่อยู่อีเมลนี้เป็นอีเมลหลักของพวกเขาได้ โทรศัพท์หลักทำงานคล้ายกัน
ระบบระบุตัวตนบางระบบอาจอนุญาตให้ลงทะเบียนหลายบัญชีด้วยชื่อผู้ใช้ที่ต่างกันแต่จับคู่กับอีเมล/โทรศัพท์เดียวกัน ซึ่งที่ Logto ไม่อนุญาต (อีเมล/โทรศัพท์สามารถเพิ่มใน customData ของ Logto) นี่เป็นเพราะอีเมลหลัก/โทรศัพท์หลักใน Logto สามารถใช้ในการเข้าสู่ระบบโดยไม่ใช้รหัสผ่าน
Logto กำหนดฟิลด์ identities นี้เป็นประเภท JSON นิยามประเภท:
ในช่วงปีหลังๆ นี้เพื่ออำนวยความสะดวกในการรับผู้ใช้ใหม่ ระบบระบุตัวตนอนุญาตให้ผู้ใช้เข้าสู่ระบบอย่างรวดเร็วผ่านบัญชีโซเชียลที่มีฐานผู้ใช้ขนาดใหญ่ เช่น google / facebook เป็นต้น
ในตัวอย่างที่ด้านล่าง ฟิลด์ identities เก็บข้อมูลการเข้าสู่ระบบทางโซเชียล:
ที่ facebook และ github เป็นชื่อเรียกของผู้ให้บริการโซเชียล userId คือ id ของบัญชีโซเชียลของผู้ใช้ที่ใช้ในการเข้าสู่ระบบ details ยังรวมข้อมูลอื่น ๆ ที่ผู้ใช้ได้อนุญาตให้ผู้ให้บริการโซเชียลแสดง ซึ่งจะถูกเพิ่มลงในโปรไฟล์ผู้ใช้ของ Logto ในเวลาที่กำหนด
ถ้าฐานข้อมูลก่อนหน้านี้มีชื่อ (เช่น facebook , google) และ id ของผู้ให้บริการโซเชียลที่ผู้ใช้ใช้ (ดู userId ในตัวอย่างก่อนหน้านี้) ผู้ใช้ Logto สามารถเข้าสู่ระบบโดยตรงด้วยบัญชีโซเชียลเดียวกันนั้น
ฟิลด์นี้สามารถเก็บข้อมูลที่เกี่ยวข้องกับผู้ใช้ได้ เช่น อีเมล/โทรศัพท์ที่กล่าวถึงข้างต้นที่ไม่สามารถใช้ในการเข้าสู่ระบบโดยไม่ใช้รหัสผ่าน (อาจใช้เพื่อรับการแจ้งเตือนหรือทำฟังก์ชันที่เกี่ยวข้องกับธุรกิจอื่นๆ)
ฟิลด์อื่นที่เหลือง่ายต่อการเข้าใจ (ยกเว้น passwordEncrypted และ passwordEncryptionMethod ซึ่งจะอธิบายในภายหลัง) โปรดอ่านเอกสารเอง
สำหรับการย้ายฐานข้อมูลขนาดใหญ่ การเขียนสคริปต์ย้ายเป็นวิธีที่พบบ่อยที่สุด เราจะให้ตัวอย่างง่าย ๆ เพื่อช่วยให้เข้าใจวิธีการเขียนสคริปต์ย้ายเพื่อให้ตรงกับความต้องการที่แตกต่าง
ควรทราบว่าเมื่อเขียนสคริปต์ย้าย เราข้ามกระบวนการดึงข้อมูลเดิมออกไปเพราะมีหลายวิธีในการรับข้อมูล เช่น การส่งออกจากฐานข้อมูลไปยังไฟล์แล้วอ่านไฟล์ หรือการดึงผ่าน APIs ซึ่งไม่ใช่จุดที่สำคัญของสคริปต์ย้าย ดังนั้นเราจะไม่กล่าวถึงในรายละเอียดที่นี่
เมื่อคุณเห็น tenant_id ในสคริปต์การย้าย คุณอาจพบว่ามันแปลก Logto เป็นบริการที่มีสถาปัตยกรรมหลายผู้เช่า สำหรับผู้ใช้ Logto open source (Logto OSS) คุณสามารถตั้ง tenant_id ของผู้ใช้เป็น default
สำหรับผู้ใช้ Logto OSS ที่ติดตั้งเอง การเชื่อมต่อฐานข้อมูลเป็นเรื่องง่ายที่จะได้รับ อย่างไรก็ตาม สำหรับผู้ใช้ Logto cloud เนื่องจากเหตุผลด้านความปลอดภัย ในปัจจุบันเราไม่สามารถให้สิทธิ์การเชื่อมต่อฐานข้อมูลแก่ผู้ใช้ได้ ผู้ใช้ต้องใช้อ้างอิงถึง API Docs และใช้ API ที่เกี่ยวข้องกับผู้ใช้ในการย้ายผู้ใช้ เราเข้าใจว่าวิธีนี้ไม่เหมาะสมสำหรับการย้ายข้อมูลผู้ใช้ขนาดใหญ่ แต่ยังสามารถจัดการการย้ายผู้ใช้จำนวนจำกัดในระยะนี้
ใน บล็อก ก่อนหน้านี้ เราได้พูดถึงบางมาตรการในการป้องกันการโจมตีด้วยพาสเวิร์ด หนึ่งในสิ่งที่ผู้ให้บริการโครงสร้างพื้นฐานระบุตัวตนสามารถทำได้คือไม่เก็บพาสเวิร์ดในรูปแบบข้อความเปล่า แต่เก็บพาสเวิร์ดที่แฮช
อีก บล็อกโพสต์ อธิบายการแฮชพาสเวิร์ด โดยที่เราได้กล่าวว่าค่าที่แฮชไม่สามารถย้อนกลับได้
บล็อกที่สองยังเปรียบเทียบวิวัฒนาการของอัลกอริทึมการแฮชบางตัว Logto เองใช้ algoritm Argon2i ที่กล่าวถึงในบทความและตอนนี้ยังไม่สนับสนุนอัลกอริทึมการแฮชอื่น ๆ ซึ่งหมายความว่าการแฮชพาสเวิร์ดจากฐานข้อมูลผู้ใช้เก่าที่ใช้ algoritm การแฮชอื่น ๆ ไม่สามารถย้ายตรงไปยังฐานข้อมูล Logto ได้
แม้ว่า Logto จะสนับสนุน algoritm การแฮชที่ใช้กันอย่างแพร่หลายในอนาคตอันใกล้ก็ตาม แต่ก็ยังยากที่จะย้ายข้อมูลเดิมโดยตรงเนื่องจากความยืดหยุ่นของเกลือ (salt) เมื่อนำ algoritm การแฮชไปใช้
นอกจากการสนับสนุน algoritm การแฮชอื่นในอนาคต Logto ยังมีแนวโน้มที่จะให้วิธีการคำนวณเกลือแบบปรับแต่งเพื่อให้เหมาะสมกับหลายสถานการณ์
ก่อนหน้านั้น คุณสามารถใช้การตั้งค่าประสบการณ์การเข้าสู่ระบบของ Logto sign-in experience configuration เพื่ออนุญาตให้ผู้ใช้เข้าสู่ระบบด้วยวิธีอื่น ๆ (เช่น อีเมล + โค้ดยืนยัน) และกรอกพาสเวิร์ดใหม่ (ซึ่งจะใช้การแฮช algoritm Argon2i) ก่อนที่จะเข้าสู่แอปฯ จากนั้นสามารถใช้พาสเวิร์ดใหม่ในครั้งต่อไปได้
ควรสังเกตว่าหากข้อมูลผู้ใช้เดิมสนับสนุนเพียงการเข้าสู่ระบบด้วยพาสเวิร์ด วิธีการที่ได้กล่าวข้างต้นจะไม่สามารถใช้ได้กับสถานการณ์นี้ นี่เป็นเพราะวิธีการที่ได้กล่าวข้างต้นจะจัดการปัญหาความไม่เข้ากันของพาสเวิร์ดแฮชโดยการใช้วิธีการเข้าสู่ระบบทางเลือกและใช้กลไก "การกรอกข้อมูลที่จำเป็น" ในกระแสการใช้งานของผู้ใช้ปลายทางของ Logto
ดังนั้นหากในข้อมูลผู้ใช้เดิมสนับสนุนเพียงการเข้าสู่ระบบด้วยพาสเวิร์ด วิธีที่ได้กล่าวข้างต้นไม่สามารถแก้ปัญหานี้ได้ เนื่องจากไม่มีทางเลือกในการเข้าสู่ระบบอื่น ๆ ที่พร้อมใช้งาน
วิธีที่ได้กล่าวข้างต้นไม่สามารถแก้ปัญหาการย้ายพาสเวิร์ดที่แฮชได้จริง ๆ แต่ให้วิธีแก้ปัญหาเชิงเลือกจากมุมมองผลิตภัณฑ์ของ Logto เพื่อหลีกเลี่ยงการขัดขวางการที่ผู้ใช้ไม่สามารถเข้าสู่ผลิตภัณฑ์ของคุณได้
หลังจากดำเนินการตามขั้นตอนด้านบนแล้ว ผู้ใช้ปลายทางสามารถเข้าสู่ระบบและใช้บริการของคุณผ่าน Logto ได้แล้ว
เนื่องจากบริการมักจะไม่ถูกตัดออกในระหว่างการย้าย จึงเป็นไปได้ว่าข้อมูลผู้ใช้ที่ซิงค์ไปยัง Logto อาจไม่เป็นข้อมูลปรับปรุง เมื่อพบกรณีที่ไม่พบบ่อยเช่นนี้ จำเป็นต้องดำเนินการซิงค์จากฐานข้อมูลเก่าไปยัง Logto
หลังจากระยะเวลายาวนานกว่า (หรืออาจใช้เมตริกที่กำหนดเองอื่น ๆ) โดยไม่มีการเกิดข้อมูลที่ไม่สอดคล้องกัน ฐานข้อมูลเดิมจะสามารถถูกละทิ้งอย่างสมบูรณ์ได้
ในโพสต์นี้ เราได้แนะนำขั้นตอนที่การย้ายฐานข้อมูลในอุดมคติจะผ่านไป
หากคุณพบปัญหาที่ไม่ได้กล่าวถึงด้านบน ไม่ต้องลังเลที่จะเข้าร่วมชุมชนของเรา หรือ ติดต่อเราเพื่อขอความช่วยเหลือ ปัญหาที่คุณพบอาจเป็นปัญหาที่ผู้อื่นก็พบเช่นกัน และจะกลายเป็นปัญหาที่เราจำเป็นต้องพิจารณาเมื่อออกแบบเครื่องมือการย้ายในอนาคต