كيفية تنفيذ وضع الضيف (المستخدمين المجهولين) باستخدام 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: دمج بيانات الضيف مع المستخدمين المصادق عليهم بأمان#

الآن اربط النقاط. استدعي واجهة برمجة التطبيقات الخلفية مع الاثنين:

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

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

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

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

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

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

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

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

الخلاصة#

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

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

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