دليل عام لنقل قاعدة بيانات المستخدم الحالية إلى Logto

لا يمتلك Logto أدوات لسلسلة نقل البيانات حتى الآن، ولكننا قمنا بفتح إمكانيات أساسية لـ Management API. هذا لن يعيق المستخدمين عن إكمال نقل قواعد بيانات المستخدم الحالية من خلال برمجة السكربتات.

نظراً لبعض الاحتياجات التي استلمناها من مستخدمي المجتمع، وحقيقة أننا لا نمتلك حالياً توثيقاً يوضح الخطوات المحددة لنقل قاعدة بيانات المستخدم، نقوم بعرض توجيه صحيح في هذا المقال لمساعدة المستخدمين في العثور على أفكار محددة وتوفير الوقت في قراءة كود Logto والتوثيقات.

الخطوة 1: فهم بنية بيانات المستخدم الأساسية والستخدامات#

يستخدم Logto قاعدة بيانات PostgreSQL في بنيته. بالإضافة إلى مزايا الأداء المختلفة، السبب المهم هو أنه يدعم نوع بيانات JSON/JSONB المخصص ويسمح ببناء فهرسة على القيم الداخلية لبيانات من النوع JSON، موازنًا بين أداء القاعدة وقابليتها للتوسع.

لمزيد من التفاصيل حول بنية بيانات المستخدم في Logto، يرجى الرجوع إلى مرجع المستخدم. هنا نركز على وصف بعض الجوانب التي قد يختلف فيها Logto عن الخدمات الأخرى لهوية المستخدمين.

id#

هذا هو معرف داخلي فريد تم إنشاؤه عشوائياً لمستخدمي Logto. لا يدرك المستخدمون وجود id عند استخدامهم لخدمات تعتمد على Logto.

المهندسون المتمرسون في قواعد البيانات لا ينبغي أن يجدوا هذا غريباً. حتى أبسط أنظمة الهوية ستحتوي على id لتحديد المستخدمين بشكل فريد، رغم أن أشكاله غالبًا ما تختلف. قد تستخدم بعض خدمات الهوية اسم المستخدم لتحديد المستخدمين بشكل فريد.

username, primaryEmail, primaryPhone#

هنا، يختلف اسم المستخدم، البريد الإلكتروني الرئيسي، والهاتف الرئيسي بشكل كبير عن أنظمة الهوية الأخرى - يمكن استخدامها جميعًا كمعرف مميز للمستخدم المرئي.

في العديد من أنظمة الهوية الأخرى، يُستخدم اسم المستخدم للتعريف (لا يمكن تكرار أسماء المستخدمين بين الحسابات)، وهذا من السهل فهمه.

ولكن في Logto، يُستخدم البريد الإلكتروني الرئيسي/الهاتف الرئيسي أيضًا لتمييز المستخدمين. أي إذا كان المستخدم A يملك البريد الإلكتروني الرئيسي [email protected]، فلا يمكن للمستخدمين الآخرين B إضافة هذا البريد الإلكتروني كبريدهم الإلكتروني الرئيسي. يعمل الهاتف الرئيسي بنفس الطريقة.

تسمح بعض أنظمة الهوية بتسجيل حسابات متعددة بأسماء مستخدمين مختلفة ولكن تربط نفس البريد الإلكتروني/الهاتف، وذلك غير مسموح به في Logto (يمكن إضافة البريدات الإلكترونية/الهاتف إلى customData في Logto). وذلك لأن البريد الإلكتروني الرئيسي/الهاتف في Logto يمكن استخدامه لتسجيل الدخول بدون كلمة مرور.

identities#

يُعرف Logto هذا الحقل identities كنوع JSON، تعريف نوعه:

في السنوات الأخيرة، لتسهيل الحصول على مستخدمين جدد، تتيح أنظمة الهوية للمستخدمين تسجيل الدخول بسرعة عبر بعض الحسابات الاجتماعية الحالية ذات القاعدة الواسعة من المستخدمين، مثل google / facebook، إلخ.

في المثال أدناه، يخزن حقل identities معلومات الدخول الاجتماعي:

حيث تمثل أسماء مقدمي الخدمات الاجتماعية facebook و github، userId هو id الحساب الاجتماعي للمستخدم المستخدم لتسجيل الدخول. كما يتضمن details بعض المعلومات الأخرى التي قام المستخدم بتفويض موفر الخدمة الاجتماعية بعرضها، والتي ستُضاف إلى ملف المستخدم في Logto في أوقات محددة.

إذا كانت قاعدة البيانات السابقة تحتوي على اسم (مثل facebook، google) و id موفر الخدمة الاجتماعية الذي استخدمه المستخدم (انظر userId في المثال السابق)، يمكن لمستخدم Logto تسجيل الدخول مباشرة باستخدام نفس الحساب الاجتماعي.

customData#

يمكن لهذا الحقل تخزين أي معلومات ذات صلة بالمستخدم، مثل البريد الإلكتروني/الهاتف المذكور أعلاه الذي لا يمكن استخدامه لتسجيل الدخول بدون كلمة مرور (قد يُستخدم لتلقي الإشعارات أو لأغراض أعمال أخرى)، إلخ.

الحقول الأخرى سهلة الفهم نسبيًا (باستثناء passwordEncrypted و passwordEncryptionMethod التي سيتم شرحها لاحقًا)، يرجى قراءة التوثيق بنفسك.

الخطوة 2: كتابة سكربتات نقل قاعدة البيانات#

لنقل قاعدة بيانات واسعة النطاق، عادةً ما يتم كتابة سكربتات النقل كأحد الأساليب الشائعة. سنقدم مثالاً بسيطاً لفهم كيفية كتابة سكربتات النقل لتلبية الاحتياجات المختلفة.

يجب ملاحظة أنه عند كتابة سكربتات النقل، نتخطى عملية استرجاع البيانات الأصلية، حيث توجد طرق عديدة للحصول على البيانات، مثل التصدير من القاعدة إلى ملفات ثم قراءة الملفات، أو الاسترجاع عبر الـ APIs. هذه ليست محور السكربت، لذا لن نناقشها بالتفصيل هنا.

عندما ترى tenant_id في السكربت، قد تجدها غريبة. يعتمد Logto على بنية متعددة المستأجرين. بالنسبة لمستخدمي Logto مفتوح المصدر (Logto OSS)، يمكنك فقط ضبط tenant_id للمستخدم على default.

بالنسبة لمستخدمي Logto OSS المستضافين ذاتياً، يمكن الحصول على اتصال قاعدة البيانات بسهولة. ومع ذلك، بالنسبة لمستخدمي Logto السحابيين، لأسباب أمنية، لا يمكننا حالياً توفير أذونات اتصال قاعدة البيانات للمستخدمين. يحتاج المستخدمون إلى الرجوع إلى وثائق API واستخدام APIs المتعلقة بالمستخدمين لنقلهم. ندرك أن هذه الطريقة لا تناسب نقل البيانات على نطاق واسع للمستخدمين، لكنها لا تزال تستطيع التعامل مع نقل عدد محدود من المستخدمين في هذه المرحلة.

الخطوة 3: تحديات نقل كلمات المرور المُشفرة والحلول الممكنة#

في مدونتنا السابقة blog، تحدثنا عن بعض التدابير لمنع هجمات كلمات المرور. أحد الأشياء التي يمكن لمزودي بنية الهوية القيام بها هو عدم تخزين كلمات المرور بنص صريح ولكن حفظ كلمات المرور المشفرة.

توضح منشور آخر عملية تشفير كلمات المرور، حيث ذكرنا أن قيم التجزئة لا يمكن تغييرها.

يقارن المنشور الثاني أيضاً تطور بعض خوارزميات التجزئة. يستخدم Logto نفسه خوارزمية Argon2i المذكورة في المقالة ولا يدعم خوارزميات التجزئة الأخرى في الوقت الحالي. وهذا يعني أن كلمات المرور المشفرة في قواعد البيانات القديمة باستخدام خوارزميات تجزئة أخرى لا يمكن نقلها مباشرة إلى قاعدة بيانات Logto.

حتى إذا دعم Logto خوارزميات التجزئة الشائعة الأخرى بالإضافة إلى Argon2i، لا يزال من الصعب نقل البيانات القديمة مباشرة بسبب مرونة استخدام الملح عند تطبيق خوارزميات التجزئة.

بالإضافة إلى دعم خوارزميات التجزئة الأخرى في المستقبل، من المرجح أن يوفر Logto طرقًا لحساب الملح المخصص لتناسب الحالات المختلفة.

قبل ذلك، يمكنك استخدام تكوين تجربة تسجيل الدخول للسماح للمستخدمين بتسجيل الدخول عبر طرق أخرى (مثل البريد الإلكتروني + رمز التحقق) وتعبئة كلمة مرور جديدة (والتي ستستخدم خوارزمية التجزئة Argon2i) قبل الدخول إلى التطبيق. ثم يمكن استخدام كلمة المرور الجديدة لتسجيل الدخول لاحقًا.

يجب ملاحظة أنه إذا كانت البيانات الأصلية للمستخدم تدعم فقط تسجيل الدخول بكلمة مرور، فإن الحل المذكور أعلاه لن يعمل في هذا السيناريو. وذلك لأن الحل المعني في الواقع يحل مشكلة عدم التوافق مع تجزئة كلمة المرور باستخدام طرق تسجيل الدخول البديلة والتسلح بآلية "إكمال المعلومات المطلوبة" في تدفق المستخدم النهائي لـ Logto.

لذلك إذا كان تسجيل الدخول بكلمة مرور هو الخيار الوحيد المدعوم في بيانات المستخدم الأصلية، فإن الحل المذكور لا يمكنه حل هذا الوضع، لأنه لا تتوافر خيارات تسجيل الدخول البديلة.

الحل المذكور هنا لا يحل بالفعل مشكلة نقل كلمات المرور المشفرة، ولكنه يوفر حلاً بديلاً من منظور منتج Logto لتجنب عرقلة المستخدمين عن تسجيل الدخول إلى منتجك.

الخطوة 4: التحويل التدريجي إلى Logto ومراقبة الحالة#

بعد استكمال الخطوات المذكورة أعلاه، يمكن للمستخدمين النهائيين تسجيل الدخول واستخدام خدمتك عبر Logto.

نظرًا لأن الخدمة عادة ما لا تُقطع أثناء النقل، من الممكن أن البيانات التي تم مزامنتها إلى Logto ليست محدثة. عندما تُكتشف مثل هذه الحالات غير الشائعة، يجب إجراء مزامنة من القاعدة القديمة إلى Logto.

بعد فترة زمنية أطول (أو تطبيق مقاييس أخرى محددة) دون وقوع بيانات غير متطابقة، يمكن التخلي عن القاعدة القديمة بشكل كامل.

الخاتمة#

في هذا المقال، قدمنا الخطوات التي يجب أن تمر بها عملية نقل قاعدة البيانات المثالية.

إذا واجهت مشاكل لم تذكر أعلاه، لا تتردد في الانضمام إلى مجتمعنا أو الاتصال بنا للحصول على المساعدة. قد تكون المشاكل التي تواجهها هي ذاتها التي يواجهها الآخرون، وستصبح قضايا يجب علينا أخذها في الاعتبار عند تصميم أدوات النقل في المستقبل.