واجهات API والمصادقة والصلاحياتBuilding APIs Authentication and Authorization

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

قبل الغوص في تفاصيل هذا الدرس، استعرض جدول المصطلحات الأساسية التالية:

في هندسة البرمجيات الحديثة، نادراً ما تكتفي الشركات بموقع ويب لأجهزة الحاسوب فقط؛ بل تحتاج المنصة نفسها إلى موقع ويب يعمل على المتصفح، وتطبيق آيفون ()، وتطبيق أندرويد (). فهل تبني الشركة ثلاث قواعد بيانات وثلاث واجهات خلفية منفصلة؟ بالطبع لا! بل يبني مطور الواجهة الخلفية واجهة برمجة تطبيقات () موحدة على الخادم:

• عقل مركزي واحد يخدم كل الشاشات: بدلاً من أن يرسل الخادم صفحات جاهزة تصلح للمتصفح فقط، يوفّر الخادم نقاط وصول للبيانات الخام المنظمة؛ فتتحدث شاشة الموقع وتطبيق الآيفون وتطبيق الأندرويد جميعاً مع نفس الخادم ونفس قاعدة البيانات.
• عقد عمل واضح بين فرق التطوير: يحدد مطور الواجهة الخلفية عنوان الرابط والحقول المطلوبة وشكل النتيجة؛ وبمجرد اعتماد هذا العقد، يعمل مطور الواجهة الأمامية ومطور الهواتف بالتوازي دون انتظار.
• حراسة قاعدة البيانات: لا يُسمح لأي متصفح أو هاتف بالاتصال بقاعدة البيانات مباشرةً أبداً، بل يمر كل طلب عبر بوابة في الخادم أولاً.

كيف ينظم مطور الواجهة الخلفية مئات المسارات البرمجية داخل الخادم دون فوضى؟ يعتمد المطورون على النمط المعماري القياسي REST ()، الذي يوظف طرق وأكواد حالة التي درستها سابقاً بشكل منظم وبديهي:

لاحظ كيف يبقى اسم المورد في الرابط واضحاً وثابتاً ()، بينما تحدد طريقة نوع العملية المطلوبة، ثم يرد الخادم بحمولة بيانات منظمة بصيغة كما في المثال الآتي:

لنفترض أن مطور الواجهة الخلفية انتهى اليوم من برمجة نقطة النهاية لإضافة طلب شراء جديد، لكن مطور الواجهة الأمامية لم يبدأ بعد في تصميم شاشة سلة المشتريات! كيف يختبر مطور الخلفية عمله؟ كتابة الرابط في شريط عنوان المتصفح ترسل طلب فقط، ولا تتيح إرسال طلب محمّل ببيانات ورؤوس رسائل مخصصة.

لهذا السبب يعتمد مطورو الواجهة الخلفية يومياً على أداة اختبار الواجهات الشهيرة Postman (أو بدائلها الخفيفة مثل Insomnia وThunder Client):

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

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

تجيب المصادقة عن سؤال واحد محدد: «من أنت؟» وهي العملية التي يتحقق فيها خادم الواجهة الخلفية من صحة هوية الشخص الذي يحاول الدخول عبر إحدى وسائل الإثبات الآتية:

• 1. شيء تعرفه (): مثل إدخال البريد الإلكتروني وكلمة المرور ومطابقتها داخل الخادم.
• 2. شيء تملكه (): مثل رمز التحقق المؤقت لمرة واحدة () الذي يصل إلى هاتفك في المصادقة الثنائية ().
• 3. تسجيل الدخول عبر مزود هوية موثوق: مثل تسجيل الدخول السريع بحساب Google أو GitHub الموثق.

بعد أن يتأكد الخادم من هويتك عبر المصادقة، تبدأ فوراً الخطوة الثانية المكملة لها: الترخيص وتحديد الصلاحيات ( وتُختصر ).

يجيب الترخيص عن سؤال حاسم: «ماذا يُسمح لك بفعله؟» فمجرد أن الطالب سجّل دخوله بنجاح بحسابه الصحيح في منصة تعليمية لا يعني أبداً أنه يملك صلاحية حذف الدورات أو تعديل درجات زملائه! ويضبط مطور الواجهة الخلفية هذه الصلاحيات عبر قاعدتين أساسيتين:

• التحكم في الوصول المبني على الأدوار (): منح كل حساب دوراً وظيفياً واضحاً مثل زائر () أو طالب () أو مدرب () أو مدير نظام ()، ولكل دور قائمة عمليات مسموحة.
• فحص ملكية المورد (): حتى بين المستخدمين الذين يحملون نفس الدور، يحق للطالب تعديل ملفه الشخصي هو فقط، ويرفض الخادم أي محاولة لتعديل ملف طالب آخر.

لكي لا يلتبس عليك الفرق بين المصادقة () والترخيص () أبداً، تذكّر تشبيه السفر عبر المطار:

• المصادقة عند موظف الجوازات: إبراز جواز سفرك لإثبات أنك فعلاً الشخص المسجل بالاسم والصورة.
• الترخيص عند بوابة الطائرة: فحص تذكرتك لمعرفة المقعد والدرجة المسموح لك بدخولها، ومنع أي راكب من دخول قمرة قيادة الطيار!

تأمل المخطط المعماري الآتي الذي يلخص تكامل نقاط نهاية مع خطوتي المصادقة والترخيص وآليتي تتبع الدخول:

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

1. 1. التحقق عند تسجيل الدخول: ترسل بريدك وكلمة مرورك إلى الخادم فيتحقق من صحتهما.
2. 2. إنشاء سجل الجلسة داخل الخادم: ينشئ الخادم في ذاكرته أو قاعدة بياناته سجلاً خاصاً بجلسة دخولك، ويرسل للمتصفح رقم الجلسة العشوائي فقط () داخل ملف تعريف ارتباط محمي ().
3. 3. إرفاق الكوكي تلقائياً مع كل طلب: في كل ضغطة تالية، يرسل المتصفح ملف الكوكي تلقائياً ضمن رأس الرسالة، فيبحث الخادم عن رقم الجلسة في سجلاته ليعرف هويتك وصلاحياتك فوراً.

بينما تعمل ملفات الكوكيز وجلسات الخادم بكفاءة عالية مع مواقع الويب التقليدية، تفضّل تطبيقات الهواتف الذكية () والواجهات المعتمدة على أسلوباً ثانياً يُعرف باسم المصادقة عديمة الحالة عبر الرموز ():

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

شاهد في المثال التوضيحي الآتي كيف يُرسل الرمز في رأس الرسالة وكيف تبدو بياناته الداخلية: