كيفية تنفيذ وضع الضيف (المستخدمون المجهولون) والتحويل إلى مستخدمي Logto

تسمح العديد من التطبيقات للمستخدمين بتجربة الميزات قبل التسجيل. فكر في عربات التسوق، مسودات المستندات، أو التفضيلات المحفوظة. يتوقع المستخدمون أن يعمل "وضع الضيف" بسلاسة.

ولكن إذا كنت تستخدم Logto (أو أي مزود OIDC) للمصادقة، قد تتساءل: كيف أتعامل مع هؤلاء المستخدمين المجهولين؟

الجواب القصير: Logto يتعامل مع المصادقة، وتطبيقك يدير جلسات الضيف. هما مواضيع منفصلة.

في هذه المقالة، سأريك نمطًا بسيطًا من ثلاث مراحل لتنفيذ وضع الضيف مع Logto. ستتعلم كيفية:

• إدارة جلسات الضيف في الخلفية
• السماح للضيوف بالتسجيل من خلال Logto
• دمج بيانات الضيف مع حساب المستخدم الفعلي

لماذا لا يوجد "تسجيل دخول مجهول" في Logto#

قد تتوقع أن يكون لدى Logto ميزة "تسجيل دخول مجهول". شيء مثل: استدعاء API، الحصول على رمز وصول، ولا حاجة لتفاعل المستخدم.

لكن هذا ليس كيف يعمل OIDC. وإليك السبب:

OIDC مبني حول موافقة المستخدم. الهدف كله هو التحقق من "من هو هذا الشخص؟". الرمز المجهول سيعني "هناك شخص ما، لكننا لا نعرف من هو" — مما يخل بالغرض.

فكر في الأمر هكذا:

• المصادقة = إثبات الهوية ("من أنت؟")
• تتبع الجلسة = تذكر الأفعال ("ماذا فعلت؟")

وضع الضيف يتعلق بتتبع الجلسة، وليس المصادقة. لذا لا ينتمي لنظام المصادقة الخاص بك.

هذا في الواقع خبر جيد. فهذا يعني أن لديك فصل واضح:

• Logto يدير الهوية (التسجيل، تسجيل الدخول، الرموز)
• تطبيقك يدير جلسات الضيف (قبل وجود الهوية)

دع كل نظام يقوم بما صُمم من أجله.

الحل ذو الثلاث مراحل#

إليك النمط: ضيف → مصادقة → دمج

المرحلة 1: إدارة جلسات الضيف بدون مصادقة#

الخلفية الخاصة بك تنشئ وتدير جلسات الضيف. لم يتدخل Logto بعد.

عندما يقوم مستخدم بإجراء مهم (مثل إضافة منتج إلى السلة)، تقوم الخلفية الخاصة بك بـ:

1. إنشاء معرف ضيف (مثلاً UUID)
2. تعيده ككوكي أو JWT
3. تخزن أفعال المستخدم تحت هذا المعرف

اجعل الأمر بسيطًا. جدول guest_sessions به guest_id، data، و created_at يكفي.

المرحلة 2: السماح للمستخدمين بتسجيل الدخول بواسطة Logto#

عندما ينقر المستخدم على "تسجيل" أو "تسجيل دخول"، أطلق تدفق OIDC القياسي لـ Logto.

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

• رمز دخول من Logto (هوية المستخدم)
• معرف الضيف من قبل (بيانات الضيف)

المرحلة 3: دمج بيانات الضيف بالمستخدمين الموثقين بأمان#

الآن اربط النقاط. استدعِ API الخلفية مع الاثنين معًا:

يجب على الخلفية التحقق من كلا الرمزين قبل الدمج:

1. التحقق من رمز الدخول → استخراج معرف المستخدم. راجع التحقق من رموز الدخول لمعرفة كيفية القيام بذلك باستخدام Logto.
2. التحقق من معرف الضيف → التأكد أنه جلسة ضيف حقيقية أصدرتها الخلفية الخاصة بك. هذا أمر بالغ الأهمية — لا تثق أبدًا بمعرف ضيف من العميل دون التحقق.

فقط بعد نجاح كلا التحققين:

3. دمج بيانات الضيف مع حساب المستخدم
4. إبطال جلسة الضيف

منطق الدمج يعتمد على طبيعة عملك. عربة تسوق؟ دمج المنتجات. مسودات مستندات؟ نقل الملكية. الخيار لك.

كيفية تأمين نقطة دمج الضيف بالتحقق من الرموز#

نقطة النهاية الخاصة بالدمج عملية حساسة. بعض الأمور التي يجب الانتباه إليها:

• دائمًا تحقق من رمز الدخول. لا تعتمد فقط على معرف المستخدم في الطلب. فك وفحص JWT. هنا كيفية ذلك مع Logto.
• دائمًا تحقق من معرف الضيف. تأكد من وجوده في قاعدة بياناتك ولم تنته صلاحيته. إذا أصدرته كـ JWT، تحقق من التوقيع.
• اشترط المصادقة. يجب أن ترفض نقطة الدمج الطلبات بدون رمز دخول صالح.
• حدد مدة صلاحية لجلسات الضيف. نظف الجلسات المهجورة بعد 30 يومًا (أو ما يناسب تطبيقك).

الخلاصة#

وضع الضيف مع Logto يتبع نمطًا بسيطًا:

1. ضيف (تطبيقك) → إدارة الجلسات قبل التسجيل
2. مصادقة (Logto) → إدارة التسجيل وتسجيل الدخول
3. دمج (تطبيقك) → ربط بيانات الضيف بالمستخدمين الفعليين

هذا النمط يعمل مع أي مزود OIDC، ليس فقط Logto. المفتاح هنا: المصادقة وتتبع الجلسة هما موضوعان منفصلان. دع كل نظام يقوم بما صُمم له.