توثيق هوية المستخدم

  • قم بإنشاء مسار لتسجيل الدخول والتسجيل باستخدام Supabase Auth وخدمة تسجيل الدخول من Google للتحكم في من يمكنه الوصول إلى تطبيقك
  • أضف برمجيات وسيطة للمصادقة إلى الخلفية الخاصة بـ Express.js لحماية مسارات واجهة برمجة التطبيقات (API) من الطلبات غير المصرح بها
  • اختبر أمان كل من الواجهة الأمامية والخلفية للتأكد من أن المستخدمين المسجلين الدخول هم وحدهم القادرون على تشغيل ميزات الذكاء الاصطناعي الخاصة بك
  • صفحات التسجيل وتسجيل الدخول التي تُنشئ حسابات المستخدمين وتحافظ على بقاء المستخدمين مسجلين الدخول
  • مسارات واجهة برمجة التطبيقات (API) المحمية باستخدام برمجيات وسيطة في الخلفية تتحقق من رموز المصادقة قبل معالجة الطلبات

قام الطلاب بإنشاء نموذج أولي قابل للتشغيل (MVP) خالٍ من الأخطاء في مستودع GitHub، يتضمن واجهة مستخدم مبنية باستخدام React وواجهة خلفية مبنية باستخدام Express.js. ويمكن تشغيل الواجهة الأمامية والواجهة الخلفية كعمليتين منفصلتين في Codespaces.

تأمين تطبيقك باستخدام المصادقة

في الوقت الحالي، يمكن لأي شخص لديه رابط Codespace الخاص بك استخدام تطبيقك. لا توجد شاشة تسجيل دخول، وتقوم الخلفية البرمجية لـ Express.js بمعالجة كل طلب تتلقاه دون أي استفسار. إذا اكتشف شخص ما عنوان URL الخاص بك، فيمكنه تشغيل استدعاءات الذكاء الاصطناعي التي تكلفك مالاً. وكما اكتشفت أثناء وضع خطتك المالية، فإن كل استدعاء لواجهة برمجة التطبيقات (API) له تكلفة. وحماية هذه الاستدعاءات ليست مجرد قرار تقني، بل هي قرار تجاري.

طوال هذه الوحدة، سنستخدم «TutorMatch» كمثال إرشادي. ستتبع أمثلة «TutorMatch»، ثم تقوم بتكييف كل خطوة لتناسب نموذجك الأولي (MVP).

توفر هذه الوحدة طبقتين من الحماية.

  1. مصادقة المستخدم — شاشة تسجيل الدخول التي تتيح للمستخدمين المسجلين فقط الاطلاع على تطبيقك. 
  2. الفحص الأمني في نظامك الخلفي للتحقق من أن كل طلب API قد جاء فعليًا من مستخدم مسجل الدخول.

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

لماذا لا تقوم بتخزين كلمات المرور بنفسك؟

النهج الأكثر بديهية في التعامل مع حسابات المستخدمين هو أيضًا الأكثر خطورة: إنشاء جدول «المستخدمين»، وتخزين عنوان البريد الإلكتروني وكلمة المرور لكل شخص عند التسجيل، والتحقق من كلمة المرور عند تسجيل الدخول.

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

 تتطلب المصادقة الآمنة تضافر عدة عوامل معًا:

  • تجزئة كلمات المرور – تحويل كلمات المرور إلى سلاسل غير قابلة للقراءة قبل تخزينها
  • رموز الجلسة – معرفات مؤقتة تحافظ على بقاء المستخدمين مسجلين الدخول دون الحاجة إلى إدخال كلمة المرور في كل صفحة
  • التخزين الآمن – معالجة بيانات الاعتماد بطريقة مشفرة بحيث لا يتم الكشف عنها أبدًا سواء أثناء النقل أو التخزين.

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

user authentication login screen

هناك عدة خيارات عند اختيار خدمة مصادقة المستخدم:

خيار

كيف يعمل

الطبقة المجانية

التعقيد

الحكم

احتفظ بكلمات المرور بنفسك

إنشاء جدول للمستخدمين ، وتشفير كلمات المرور باستخدام خوارزمية التجزئة، وإدارة الجلسات يدويًّا

مجاناً

مرتفع — من السهل ارتكاب أخطاء أمنية، وهي خطيرة

غير مُوصى به للمنتجات الأولية القابلة للتطبيق (MVPs).

تسجيل الدخول عبر Google (OAuth)

ينقر المستخدمون على «تسجيل الدخول باستخدام Google». وتتكفل Google بجميع الإجراءات الأمنية.

مجاناً

متوسط — يتطلب إعداد Google Cloud Console

خيار رائع، لكنه يتطلب خطوات إضافية للإعداد

Auth0 / موظف

خدمات المصادقة التابعة لجهات خارجية المزودة بصفحات تسجيل دخول جاهزة

يتوفر برنامج مجاني

Medium — يلزم إنشاء حساب جديد واستخدام SDK

جيد، لكنه يضيف خدمة أخرى يتعين إدارتها

توثيق Supabase

مُدمج في Supabase. يتولى معالجة التجزئة والجلسات والتخزين تلقائيًا.

مجاني (مشمول)

منخفض — لديك بالفعل حساب على Supabase

خيار رائع لـ MVP

سنستخدم «Supabase Auth» لتوثيق هوية المستخدمين في هذا الدرس. كما سنضيف ميزة تسجيل الدخول عبر Google، حيث إنها خيار تسجيل دخول قياسي للتطبيقات الاحترافية، ولا يتطلب إعدادها صعوبة كبيرة. ويُعد «Supabase Auth» الخيار الرئيسي لثلاثة أسباب:

  1. لديك بالفعل حساب على Supabase من خلال «مجموعة أدوات المؤسس».
  2. تتولى Supabase معالجة جميع الجوانب الأمنية المعقدة المذكورة أعلاه بشكل تلقائي.
  3. تغطي الخطة المجانية كل ما تحتاجه لنموذجك الأولي القابل للتسويق (MVP).

هناك أمر آخر يجب أخذه في الاعتبار: يدعم Supabase Auth ميزة «الأمان على مستوى الصفوف» (RLS)، وهي قواعد قاعدة البيانات التي تقوم بتكوينها لتصفية البيانات بحيث لا يتمكن كل مستخدم من رؤية سوى السجلات الخاصة به. وقد تطرقنا إلى هذا الموضوع عندما أضفنا Supabase إلى «مجموعة أدوات المؤسس» الخاصة بنا. إلا أن ميزة RLS لن تحمي مسارات الذكاء الاصطناعي الخاصة بك. ولهذا السبب نحتاج إلى إضافة المزيد من إجراءات الحماية.

«لا حاجة إلى RLS في هذه المرحلة، لأننا لا نقوم بإنشاء أي جداول مخصصة. تتولى Supabase إدارة تخزين بيانات المستخدمين داخليًّا. وتصبح RLS ذات صلة إذا كنت تقوم بتخزين بيانات خاصة بالمستخدم في نموذج المنتج القابل للتسويق (MVP) — مثل حفظ سجل المستخدم أو تفضيلاته أو معاملاته.»

المصادقة في Supabase

عند إنشاء مشروع على Supabase، يتم تمكين المصادقة تلقائيًا. ولا تحتاج إلى إجراء أي إعدادات خاصة في إعدادات Supabase. صحيح أننا قمنا بإعداد بعض سياسات الأمان RLS المحددة في «مجموعة أدوات المؤسس» (Founder’s Toolkit) للمستخدمين المجهولين مقارنة بأعضاء الفريق، ولكن بالنسبة لهذه القاعدة البيانات، سنستخدم المصادقة الافتراضية المدمجة في Supabase.

ما تقوم Supabase بتكوينه تلقائيًا:

  •  تم تمكين المصادقة عبر البريد الإلكتروني/كلمة المرور
  • تم إنشاء جدول المستخدمين (auth.users)
  • تم إصدار رموز JSON Web Tokens (JWT)
  • تمت معالجة إدارة الجلسات

في النشاط الأول، ستقوم بإضافة مسار لتسجيل الدخول والتسجيل إلى نموذج المنتج القابل للتطبيق (MVP) الخاص بك، بحيث لا يتمكن سوى المستخدمين المسجلين من الوصول إلى تطبيقك. وسنقوم بتنفيذ سلسلة من الخطوات، مع إجراء اختبار بعد كل خطوة للتأكد من أن كل شيء يعمل بشكل صحيح قبل الانتقال إلى الخطوة التالية. 

تستخدم كل موجهة في أنشطة هذا الدرس هيكل "الدور + المهمة" . وهذا نمط هندسي لكتابة المطالبات يستحق الممارسة:

  • الدور يحدد للذكاء الاصطناعي نوع الخبير الذي يجب أن يكون عليه
  • المهمة تحدد له بالضبط ما يجب أن يفعله.

إن الفصل بين هذين الأمرين يجعل أوامرك أكثر وضوحًا ويؤدي إلى نتائج أفضل، لا سيما مع نماذج الذكاء الاصطناعي الأصغر حجمًا.

النشاط 1

إضافة ميزة مصادقة المستخدمين باستخدام Supabase

الوقت المقدر: 30 دقيقة

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

  1. انتقل إلى GitHub وافتح مستودع MVP الخاص بك. 
  2. أنشئ فرعًا جديدًا باسم مثل «add-auth». 
  3. افتح «Codespace» الخاص بك على الفرع الجديد.

أنت على وشك إجراء تغييرات جوهرية — فرع الميزات يحافظ على سلامة الفرع الرئيسي. ولن تقوم بدمج التغييرات في الفرع الرئيسي إلا بعد إجراء الاختبارات.

  1. انتقل إلى Supabase. يجب أن يكون لديك حساب ومشروع من «مجموعة أدوات المؤسس».
  2. أنشئ مشروعًا جديدًا. اختر له اسمًا مناسبًا لنموذجك الأولي (MVP).
  3. ستحتاج إلى إنشاء كلمة مرور لقاعدة البيانات. قم بإنشاء كلمة مرور واحتفظ بها في مكان آمن، حيث لن تتمكن من رؤيتها بعد حفظها.
  4. تكوين إعدادات المصادقة:
    1. انتقل إلى لوحة تحكم Supabase → المصادقة → الإعدادات
    2. قم بالتمرير لأسفل حتى تصل إلى قسم «تسجيل الدخول/مقدمو الخدمات »
    3. ابحث عن «تمكين تأكيدات البريد الإلكتروني»
    4. قم بتعطيله (لأغراض الاختبار)
    5. تذكر إعادة تشغيله عندما تنتقل إلى مرحلة الإنتاج!
supabase user authentications screen
  1. احصل على رابط مشروعك ومفاتيح واجهة برمجة التطبيقات (API)
    1. في الشريط الجانبي الأيسر، انقر على «إعدادات المشروع » (رمز الترس في الأسفل)
    2. انقر على «واجهة برمجة تطبيقات البيانات».
    3. سترى عنوان URL الخاص بواجهة برمجة التطبيقات (API). انسخه واحفظه في مكان ما على جهاز الكمبيوتر الخاص بك. ستحتاج إليه لتطبيقك.
    4. ارجع إلى قائمة «إعدادات المشروع» وانقر على «مفاتيح واجهة برمجة التطبيقات».
    5. سترى مفتاحين، هما المفتاح القابل للنشر والمفتاح السري.
    6. انسخ المفتاح القابل للنشر. ستحتاج إليه في تطبيقك أيضًا.

كل من عنوان URL العام والمفتاح القابل للنشر متاحان ويمكن استخدامهما في الواجهة الأمامية لتطبيقك. ونظرًا لأن Supabase تستخدم نظام RLS (الأمان على مستوى الصفوف)، فإن البيانات محمية. يمكن للمستخدمين التسجيل وتسجيل الدخول، لكنهم لا يمكنهم رؤية سوى بياناتهم الخاصة، ولا يتم منحهم صلاحيات إدارية.

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

  1. في مشروعك، أضف ملفًا جديدًا باسم ملف .env في المجلد المجلد الجذر. سيكون لديك بالفعل ملف .env في الخادم ، ولكن نظرًا لأن تكامل Supabase يحدث في الواجهة الأمامية، فيجب أن يكون موجودًا في الدليل الجذري للمشروع.
  2. أضف سطرين إلى ملف الجذر .env
    VITE_SUPABASE_URL=your_public_URL
    VITE_SUPABASE_KEY=your_publishable_key
  3. أضف عنوان URL الفعلي لحسابك على Supabase ومفتاح النشر إلى تلك الأسطر في الملف.

ملاحظة: نحن نستخدم React، لذا يلزم إضافة البادئة VITE_ إلى متغيرات بيئة الواجهة الأمامية. قد يختلف إطار العمل الذي تستخدمه عن ذلك.

في محطة Codespace الخاصة بك، اكتب: `
` `npm install @supabase/supabase-js`

اطلب من Copilot (أو أي نموذج لغوي كبير آخر) مساعدتك في إنشاء رمز تسجيل الدخول/التسجيل لتطبيقك. وإليك مثال على نص الطلب.

الدور: أنت مطور ويب تساعدني في دمج ميزة مصادقة المستخدمين في تطبيقي الذي يعمل بتقنية React.

المهمة: أضف نموذج تسجيل وتسجيل دخول لـ Supabase وتفاعل مع رابط Supabase. الشاشة الافتتاحية هي شاشة تسجيل الدخول، وبمجرد قيام المستخدم بتسجيل الدخول، تظهر علامتا التبويب الأخريان ويمكن للمستخدم الوصول إلى هاتين العلامتين. يجب إضافة نموذج تسجيل الدخول كملف Authform.jsx في مجلد Pages. أضف زر «تسجيل الخروج» إلى الشاشة بمجرد تسجيل دخول المستخدم، بجانب أزرار علامات التبويب الأخرى، حتى يتمكن المستخدم من تسجيل الخروج والعودة إلى الشاشة الرئيسية.

استخدم في «AuthForm» نفس التنسيق الذي استخدمته في علامتي التبويب «FindTutor» و«GetAdvice». 

لقد أضفت عنوان URL لمشروع Supabase ومفتاح API القابل للنشر إلى ملف .env الخاص بي تحت اسمي VITE_SUPABASE_URL و VITE_SUPABASE_URL. 

اختبر المسار الكامل:

  1. التسجيل:
    • انتقل إلى /signup
    • أدخل عنوان البريد الإلكتروني وكلمة المرور (6 أحرف على الأقل)
    • انقر على «التسجيل»
    • يجب إعادة التوجيه إلى الصفحة الرئيسية
  2. التحقق في Supabase:
    • افتح لوحة تحكم Supabase → المصادقة → المستخدمون
    • من المفترض أن ترى اسم المستخدم الجديد مدرجًا في القائمة
  3. تسجيل الخروج:
    • انقر على زر «تسجيل الخروج»
    • يجب إعادة التوجيه إلى صفحة تسجيل الدخول
  4. تسجيل الدخول:
    • أدخل نفس عنوان البريد الإلكتروني/كلمة المرور
    • يجب إعادة التوجيه إلى الصفحة الرئيسية
  5. استمرارية الجلسة:
    • تحديث الصفحة
    • من المفترض أن تكون لا تزال مسجلاً الدخول

إذا فشلت أي خطوة، فاستخدم نمط «Teach Me» مع Copilot: صِف ما كنت تتوقعه، وما حدث بدلاً من ذلك، واطلب من Copilot أن يشرح لك الأمر قبل تقديم حل.

اترك «Codespace» والفرع مفتوحين من أجل النشاط التالي.

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

النشاط 2

(اختياري) إضافة ميزة تسجيل الدخول عبر Google

الوقت المقدر: 30 دقيقة

  1. انتقل إلى لوحة تحكم Supabase → المصادقة → مزودي الخدمة.
  2. ابحث عن «Google» في القائمة وقم بتفعيله. 
  3. ابحث عن عنوان URL الخاص بالاستدعاء (Callback URL) وانسخه. وعادةً ما يكون على الشكل التالي: https://[YOUR-PROJECT-ID].supabase.co/auth/v1/callback.

هام: تجاهل اللافتات الكبيرة التي تحمل عبارة «جرب مجانًا» أو «تفعيل رصيد بقيمة 300 دولار» الموجودة في أعلى الشاشة. إذا نقرت على هذه الأزرار، فستطلب منك Google إدخال بيانات بطاقة ائتمان للتحقق من هويتك.

لا تحتاج إلى الرصيد البالغ 300 دولار أو إلى «حساب فوترة» لاستخدام واجهات برمجة التطبيقات (API) الخاصة بالهوية/المصادقة.

  1. انتقل إلى Google Cloud Console. من المفترض أن يكون لديك حساب من استخدام Google AI Studio.

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

  3. انتقل إلى «واجهات برمجة التطبيقات والخدمات» → «شاشة موافقة OAuth».

    • انقر على «ابدأ».
    • أدخل اسم التطبيق وعنوان البريد الإلكتروني الخاص بدعم المستخدمين.
    • انقر خارجي للجمهور.

      هام: لا تقم بتقديم سوى «اسم التطبيق» و«البريد الإلكتروني للدعم». إذا طلبوا منك إضافة شعار أو «نطاقات» حساسة (مثل قراءة محتوى «Drive» الخاص بالمستخدم بالكامل)، فقد تقوم Google بوضع علامة على التطبيق لإخضاعه للتحقق باستخدام بطاقة ائتمان.

      نصيحة للمشاركين في برنامج MVP:       لا داعي لتقديم طلب التحقق بعد طالما أنك لا تزال في وضع «الاختبار» أو أن عدد المستخدمين قليل.

  1. انتقل إلى «واجهات برمجة التطبيقات والخدمات» → «بيانات الاعتماد».
  2. انقر على «+ إنشاء بيانات اعتماد» → «معرف عميل OAuth».
  3. نوع التطبيق: حدد «تطبيق ويب».
  4. عناوين URI المعتمدة لإعادة التوجيه: الصق عنوان URL الخاص بالاستدعاء المرتد الذي نسخته من Supabase أعلاه.
  5. انقر على «إنشاء». ستتلقى «معرّف العميل » و «السر الخاص بالعميل».
  6. تأكد من نسخ هذه البيانات، لأنك لن تتمكن من الوصول إليها عند إغلاق النافذة. يمكنك تنزيلها بتنسيق JSON لتكون متاحة لك في كلا الصيغتين.
  1. ارجع إلى لوحة تحكم Supabase → المصادقة → مزودي الخدمة → Google.
  2. الصق معرّف العميل (Client ID) ورمز السر الخاص بالعميل (Client Secret).
  3. اضبط خيار «تمكين مزود Google » على «تشغيل » وانقر على «حفظ».

عندما يقوم المستخدم بتسجيل الدخول باستخدام حساب Google، يجب أن يعرف الموقع الذي سيعود إليه بعد المصادقة. سيتم توجيهه افتراضيًّا إلى http://localhost:3000/ ، لكن واجهة المستخدم الخاصة بنا تعمل على http://localhost:5173.

  1. لضمان عملها، انسخ رابط Github أثناء تشغيل التطبيق (سيكون شكله تقريبًا كالتالي: https://codespace_name.app.github.dev/
  2. في Supabase، انتقل إلى «المصادقة» → «تكوين عناوين URL». 
  3. أضف رابط Github الخاص بك كرابط إعادة توجيه.
  1. أضف رابط Github Codespace في ملف .env كمتغير، VITE_DEVELOPMENT_URL (لا يلزم استخدام VITE إلا إذا كان تطبيقك مبنياً على React).

ستطلب من «Copilot» إضافة ميزة تسجيل الدخول عبر Google. يرجى ملاحظة أننا نضيف تعليمات تتضمن عنوان URL الخاص بإعادة التوجيه. 

  1. اطلب من «Copilot» إضافة تسجيل الدخول عبر Google كخيار في شاشة تسجيل الدخول الخاصة بك.

الدور: أنت مطور ويب تساعدني في دمج ميزة مصادقة المستخدمين في تطبيقي الذي يعمل بتقنية React.

المهمة: إضافة تسجيل الدخول عبر Google كخيار إلى صفحة تسجيل الدخول الخاصة بي. استخدم طريقة signInWithOAuth في Supabase مع مزود الخدمة «Google». قم بإعادة التوجيه إلى متغير البيئة VITE_DEVELOPMENT_URL.

ملاحظة: إذا قمت بالتبديل بين مساحات البرمجة، فسيتعين عليك إنشاء ملف .env جديد يتضمن إعادة التوجيه الخاصة بك (بالإضافة إلى عنوان URL الخاص بـ Supabase ومفتاح API الخاص بواجهة المستخدم الأمامية).

عندما تبدأ في نشر تطبيقك، سيتعين عليك إضافة عنوان URL الخاص بتطبيقك في بيئة الإنتاج كإعادة توجيه في Supabase، وكذلك إضافته كإعادة توجيه في الكود الخاص بك.

  1. قم بتسجيل التغييرات التي أجريتها في الفرع الخاص بك.

اترك الفرع و«Codespace» مفتوحين من أجل النشاط التالي.

تأمين مسارات واجهة برمجة التطبيقات (API) الخاصة بك

أصبح لدى تطبيقك الآن صفحة تسجيل دخول، لذا يتعين على المستخدمين تسجيل الدخول لمشاهدة التطبيق. لكن الخادم الخلفي الذي يعمل بنظام Express.js لا يزال يعالج كل طلب يتلقاه، حتى لو لم يقم المستخدم بتسجيل الدخول عبر الواجهة الأمامية. فقد يقوم شخص ما بفتح وحدة التحكم في المتصفح واستدعاء واجهة برمجة التطبيقات (API) الخاصة بك مباشرةً، متجاوزًا صفحة تسجيل الدخول تمامًا.

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

يجب عليك:

حماية المسارات التي:

  • تكلفة مالية (مكالمات الذكاء الاصطناعي، استخدام واجهة برمجة التطبيقات)
  • تعديل البيانات (إنشاء، تحديث، حذف)
  • عرض المعلومات الخاصة بالمستخدم

إبقاء الحالة عامة:

  • الفحوصات الطبية
  • الأصول الثابتة
  • الصفحة الرئيسية (إذا كانت متاحة للعامة)

عندما تتلقى البنية الخلفية طلبًا:

  1. تحقق مما يلي: «هل تضمن هذا الطلب دليلاً على أن المستخدم قد قام بتسجيل الدخول؟»
  2. إذا كانت الإجابة «نعم» → معالجة الطلب كالمعتاد
  3. إذا لم يكن هناك → رفض الطلب مع ظهور خطأ «401 غير مصرح به»

«الدليل» هو JWT (JSON Web Token)، وهو سلسلة طويلة من الأحرف تمنحها Supabase لكل مستخدم مسجل الدخول. تقوم واجهة المستخدم الخاصة بك بتضمين هذا الرمز في كل طلب ترسله إلى الخلفية. تقوم الخلفية بالتحقق من الرمز مع Supabase للتأكد من صحته ومن أنه لم تنته صلاحيته.

ما يحتويه:

  • هوية المستخدم (معرّف المستخدم، البريد الإلكتروني)
  • تاريخ إصداره
  • عند انتهاء صلاحيتها
  • توقيع تشفير يثبت أن Supabase هي الجهة التي أصدرته وأنه لم يتم العبث به
النشاط 3

تأمين مسارات واجهة برمجة التطبيقات (API) الخاصة بك

المدة التقديرية: 25 دقيقة

إذا لم تكن قد دخلت إلى Codespace بعد، فافتحه، مع استخدام نفس الفرع الذي استخدمته في النشاطين 1 و2.

  1. في الخادم المجلد (الذي توجد فيه الخلفية الخاصة بـ Express)، قم بتثبيت Supabase:
    • في نافذة سطر الأوامر، اكتب:
      cd server
      npm install @supabase/supabase-js
  1. ارجع إلى مشروع Supabase الخاص بك، واحصل على مفتاح API السري (وليس المفتاح القابل للنشر).
    • انتقل إلى «إعدادات المشروع» → «مفاتيح واجهة برمجة التطبيقات»
    • قم بالتمرير لأسفل حتى تصل إلى «المفتاح (المفاتيح) السري (السرية)».
    • انسخه واحفظه في مكان آمن على جهاز الكمبيوتر الخاص بك.
  2. تحديث ملف ملف .env في خادمك الخادم (وليس ملف .env الموجود في الجذر – بل ملف server/.env هو ملف منفصل للخلفية).
  3. أضف هذه الأسطر، مع لصق عنوان URL الخاص بـ Supabase ومفتاحك السري:
    SUPABASE_URL=your_public_URL
    SUPABASE_SERVICE_ROLE_KEY=your_secret_key

هام:

  • استخدم نفس عنوان SupaBase_URL المستخدم في واجهة المستخدم الأمامية
  • استخدم «المفتاح السري » (وليس المفتاح القابل للنشر) لقيمة SUPABASE_SERVICE_ROLE_KEY
  • يتمتع المفتاح السري بامتيازات المسؤول – لا تكشف عنه أبدًا في كود الواجهة الأمامية
  1. استخدم هذه التوجيهات لتطلب من Copilot إضافة كود إلى كود الخلفية لضمان أمان استدعاءات واجهة برمجة التطبيقات (API).

الدور: أنت مطور خلفي تساعدني في تأمين واجهة برمجة التطبيقات (API) الخاصة بي التي تعمل بنظام Express.js.

المهمة: 

  1. استيراد مكتبة عميل Supabase (@supabase/supabase-js)
  2. تهيئة عميل Supabase باستخدام SUPABASE_URL و SUPABASE_SERVICE_ROLE_KEY من متغيرات البيئة.
  3. أضف وظيفة برمجية وسيطة للمصادقة إلى الخلفية الخاصة بي في Express.js.
    • استخراج الرمز المميز
    • اطلب من Supabase التحقق من صحة الرمز المميز
    • إذا كانت الإجابة «نعم» → السماح باستمرار الطلب
    • إذا لم يكن هناك → إرجاع خطأ 401

  4. لا تُطبق هذه البرمجيات الوسيطة إلا على المسارات التي تستدعي واجهات برمجة التطبيقات الخارجية

  5. لا تقم بتطبيقه على المسارات العامة مثل الصفحة الرئيسية أو فحص الحالة

  1. راجع الكود الذي تم إنشاؤه.

    من المفترض أن ترى دالة تُسمى requireAuth (أو اسمًا مشابهًا) تتحقق من وجود رأس «Authorization»، وتستخرج الرمز المميز (token)، وتتحقق من صحته مع Supabase. كما يجب أن ترى أنها مطبقة على مسار واجهة برمجة التطبيقات (API) الخاص بك، ولكنها غير مطبقة على المسارات العامة.

    يجب أن تبدو الأجزاء الرئيسية مشابهة لهذا الكود:
				
					async function requireAuth(req, res, next) {
  const authHeader = req.headers.authorization;

  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Unauthorized' });
  }

  const token = authHeader.split(' ')[1];
  const { data, error } = await supabase.auth.getUser(token);

  if (error || !data.user) {
    return res.status(401).json({ error: 'Unauthorized' });
  }

  req.user = data.user;
  next();
}

// Protected route — security check runs first
app.post('/api/ai-query', requireAuth, async (req, res) => {
  // This code only runs if the user is logged in
});

// Public route — no security check needed
app.get('/health', (req, res) => {
  res.json({ status: 'ok' });
});

بالنسبة إلى TutorMatch، المسار المحمي هو app.post(‘/api/ai-query’, requireAuth, …). سيكون لتطبيقك أسماء مسارات مختلفة، لكن النمط واحد — وهو حماية المسارات التي يتكلف تشغيلها أموالاً.

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

  1. اطلب من Copilot تحديث كود الواجهة الأمامية الخاص بك. إليك مثال على الطلب.

الدور: أنت مطور واجهة مستخدم تساعدني في ربط تطبيق React الخاص بي بخادم Express.js الخلفي الآمن.

المهمة: تحديث جميع استدعاءات واجهة المستخدم لـ API الخاصة بي لتتوافق مع المسارات المحمية، بحيث يتم تضمين رمز جلسة Supabase في رأس «Authorization».

  1. انظر إلى الكود الذي قام «Copilot» بتحديثه.

    ستلاحظ أن طلبات الاسترداد الخاصة بك تتضمن الآن رأس «Authorization». وإليك شكل التغيير:
				
					const { data: { session } } = await supabase.auth.getSession();

if (!session) {
  window.location.href = '/login';
  return;
}

const response = await fetch('/api/ai-query', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': `Bearer ${session.access_token}`
  },
  body: JSON.stringify({ prompt: userInput })
});

هنا يترابط كل شيء:

  1. تمنح خدمة Supabase Auth واجهة المستخدم الخاصة بك رمزًا مميزًا عند قيام المستخدم بتسجيل الدخول.
  2. تقوم واجهة المستخدم الخاصة بك بإرسال هذا الرمز مع كل طلب.
  3. يقوم نظام الخلفية الخاص بك بالتحقق من ذلك.
    • إذا كان الطلب صالحًا، فسيتم تنفيذه.
    • وإلا، فهذا يعني أنه محجوب.
  1. قم بتشغيل تطبيقك في Codespaces واختبر سيناريوهين:

الاختبار 1 — مستخدم مسجل الدخول (من المفترض أن يعمل):

    1. افتح التطبيق وقم بتسجيل الدخول باستخدام بيانات اعتمادك التجريبية.
    2. استخدم ميزة الذكاء الاصطناعي الخاصة بك كالمعتاد.
    3. من المفترض أن يعمل الأمر تمامًا كما كان من قبل.

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

الاختبار 2 — بدون تسجيل دخول (يجب حظره):

    1. قم بتسجيل الخروج من التطبيق، بحيث لا يكون المستخدم مسجلاً للدخول.
    2. افتح «أدوات المطور» (DevTools ) (بالضغط على المفتاح F12 أو النقر بزر الماوس الأيمن واختيار «فحص» (Inspect))، ثم انقر فوق علامة التبويب «وحدة التحكم» (Console ).
    3. حاول استدعاء واجهة برمجة التطبيقات (API) الخاصة بك مباشرةً عن طريق لصق ما يلي في وحدة التحكم (ملاحظة: أمر الاستردادالخاص بنا هو /api/ai-query – قم بتعديل أمر الاسترداد الخاص بك لاستخدام الأمر نفسه الموجود في كود الواجهة الأمامية.)
				
					fetch('/api/ai-query', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ prompt: 'test' })
}).then(r => r.json()).then(console.log);

You should see { error: “Unauthorized” } — NOT an AI response.

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

  1. تحقق مرة أخيرة للتأكد من أن عملية مصادقة المستخدم تعمل بشكل صحيح:

    • قم بتسجيل الخروج تمامًا وقم بتحديث الصفحة — ومن المفترض أن تظهر لك صفحة تسجيل الدخول
    • سجّل الدخول وتأكد من أن ميزة الذكاء الاصطناعي تعمل
    • افتح وحدة تحكم DevTools وحاول استدعاء واجهة برمجة التطبيقات (API) الخاصة بك بدون الرمز المميز (كما في الاختبار 2) — تأكد من ظهور خطأ 401

  2. قم بـ«stage» التغييرات الخاصة بك و«commit»ها في نظام التحكم في المصادر، مع إضافة رسالة مثل «إضافة حماية لمسار واجهة برمجة التطبيقات (API) باستخدام برمجيات وسيطة للمصادقة»، ثم قم بـ«push»ها إلى الفرع الخاص بك.

  3. انتقل إلى Github، وأنشئ طلب سحب (Pull Request) من فرع add-auth الخاص بك، وراجع التغييرات، ثم قم بدمجها في الفرع الرئيسي. 

استكشاف الأخطاء وإصلاحها

فيما يلي بعض المشكلات التي قد تنشأ، والحلول الممكنة لها

افتح DevTools، ثم انتقل إلى علامة التبويب «الشبكة»، ثم انقر على طلب API، واطلع على «رؤوس الطلبات». من المفترض أن ترى «Authorization: Bearer eyJ…». إذا كان الرأس مفقودًا، فتأكد من أن استدعاء getSession() يعمل بشكل صحيح.

تأكد من أنك قمت بتطبيق requireAuth على المسار الصحيح.

تأكد من استخدام SUPABASE_SERVICE_ROLE_KEY (وليس SUPABASE_ANON_KEY) في الخلفية. يمتلك مفتاح دور الخدمة صلاحية التحقق من الرموز المميزة لأي مستخدم.

تأكد من تثبيت مكتبة عميل Supabase (npm install @supabase/supabase-js) واستيرادها في أعلى ملف الخادم الخاص بك.

الانعكاس

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

Sunset and reflection over lake
01

Security
ما الذي قد يحدث إذا لم يكن لديك سوى صفحة تسجيل الدخول دون أي إجراءات أمنية في الخلفية؟
02

مسارات واجهة برمجة التطبيقات (API) الخاصة بك
في نموذج المنتج القابل للتسويق (MVP) الخاص بك، ما هي المسارات التي تحتاج إلى برمجيات وسيطة للمصادقة، وأيها يمكن أن تظل عامة؟ كيف اتخذت قرارك؟
03 التوجيه في لعبة «

»
كيف أثرت بنية «الدور + المهمة» على جودة الكود الذي تم إنشاؤه بواسطة الذكاء الاصطناعي؟ وهل تختلف هذه النتائج (للأفضل أو للأسوأ) عن نتائج المطالبات السابقة؟

المصطلحات الرئيسية

  • المصادقة: التحقق من هوية المستخدم — التأكد من أنه هو بالفعل من يدعي أنه هو (التسجيل وتسجيل الدخول). وتختلف عن التفويض، الذي يتحكم في ما يمكن للمستخدم الوصول إليه.
  • التفويض: التحكم في الإجراءات المسموح بها للمستخدم الذي تمت مصادقته. ويُعد الأمان على مستوى الصفوف (RLS) إحدى الطرق لتنفيذ ذلك على مستوى قاعدة البيانات.
  • تجزئة كلمة المرور: تحويل كلمة المرور إلى سلسلة أحرف غير قابلة للقراءة قبل تخزينها. يقوم Supabase Auth بذلك تلقائيًا. ويُعد تخزين كلمات المرور بنص عادي خطرًا أمنيًا جسيمًا.
  • رمز الجلسة: معرّف مؤقت يحافظ على بقاء المستخدم مسجّل الدخول بعد إتمام عملية المصادقة. وتقوم «Supabase Auth» بإدارة هذه الرموز تلقائيًا.
  • برمجيات وسيطة للمصادقة: شفرة برمجية تُنفَّذ قبل معالج المسار للتحقق من أن الطلب صادر عن مستخدم مسجَّل الدخول. إذا لم يتم مصادقة المستخدم، فإن البرمجيات الوسيطة تحجب الطلب.
  • رأس التفويض: رأس HTTP ينقل بيانات المصادقة (عادةً رمزًا مميزًا) من الواجهة الأمامية إلى الخلفية مع كل طلب.
  • Bearer Token: A type of authentication token sent in the Authorization header. The format is Bearer <token>. “Bearer” means “whoever carries this token is authorized.”
  • JSON Web Token (JWT): تنسيق قياسي لرموز المصادقة. يحتوي على معلومات مشفرة عن المستخدم وموعد انتهاء الصلاحية. تستخدم Supabase رموز JWT لإدارة الجلسات.
  • OAuth: معيار للمصادقة يتيح للمستخدمين تسجيل الدخول باستخدام حساب موجود (مثل Google) بدلاً من إنشاء كلمة مرور جديدة. وهو اختصار لعبارة «Open Authorization».

الموارد الإضافية

محتوى الدرس
الاختبار السابق
العودة إلى الدورة
الاختبار التالي