باستخدام إصدار الإطار العمل Laravel 5.3.9، والذي تم تحميله حديثًا دون إضافات عبر Composer (باستثناء “laravel/passport”: “^1.0”)، تم اتباع جميع الخطوات المقترحة في الوثائق الخاصة بـ Passport. تم إنشاء الجداول وتعيين المسارات، وكل شيء يعمل بشكل جيد. ومع ذلك، يتعين استخدام Passport لإنشاء واجهة برمجة تطبيقات (API).
المسارات تبدو كما يلي:
كل المسارات الخاصة بـ “web” موجودة، ولا توجد مسارات متعلقة بـ “api”، نظرًا لعدم توفير Passport أي شيء من هذا القبيل بشكل افتراضي.
الهدف من الواجهة هو استخدامها من قبل عميل موثوق به، حيث أنها مخصصة لتطبيق محمول يتطلب تسجيل دخول، ولكن عملية تسجيل الدخول ستتجاوز بعض الخطوات. عندما يصل المستخدم إلى مسار “/register”، يتمتع عملية التسجيل نفسها بالبساطة: يتم الوصول إلى حساب Facebook للمستخدم والحصول على بعض الحقول – البريد الإلكتروني، ومعرف Facebook، والاسم، وصورة الملف الشخصي – ومن هذه النقطة فصاعدًا يُعتبر المستخدم مسجّلاً. ومع ذلك، لن يقوم المستخدم بتسجيل الدخول باستخدام Facebook. سيتم إصدار رمز مميز لتطبيق المستهلك واستخدام ذلك الرمز للوصول إلى مختلف نقاط نهاية الواجهة التي تتطلب رمزًا للاستخدام.
من الواضح أن Passport يُسبب صداعًا عند العمل معه لتنفيذ ما يتعلق بالواجهة البرمجية (API)، سواء كان ذلك بسبب صعوبة التنفيذ أو بسبب عدم القدرة على فهم كيفية عمله بشكل صحيح.
تم إنشاء عميل اختباري في جدول “oauth_clients” على النحو التالي:
باستخدام Postman للوصول إلى مسار “api/v1/users/register” الذي يحتوي على middleware “auth” مع JSON التالي:
{
“grant_type”: “authorization_code”,
“client_id”: 5,
“client_secet”: “y5dvPIOxQJOjYn7w2zzg4c6TRrphsrNFWbG4gAUL”
}
والذي من المفترض أن ينتج في:
{“error”: “Unauthenticated.”}
من المنطقي تمامًا. بغية الفضول فقط، تم تغيير المسار “/register” إلى:
وذلك أدى إلى:
{“error”: “invalid_client”, “message”: “Client authentication failed”}
تم تتبع الدالة التي تدير الجزء المتعلق بـ “validateClient” في:
العميل هو null. قد يكون هذا مرتبطًا بـ Passport، حيث أن الوثائق المتعلقة به ناقصة نوعًا ما، وفكرة البحث في حزمة ضخمة لتتبع الخطأ الذي قد يكون بسببي بشكل كبير لا تبدو فكرة جيدة. بصراحة، في هذه المرحلة، أي توجيه نحو الاتجاه الصحيح هو أكثر من مرحب به.
المزيد من المعلومات
المشكلة تبدو معقدة وتحتاج إلى فحص دقيق لفهم السبب الحقيقي وراءها. يمكن أن يكون الخطأ ناتجًا عن عدة عوامل، بما في ذلك الإعدادات الخاصة بـ Passport، أو استخدام الـ Middleware بشكل غير صحيح، أو الطريقة التي تم فيها تكوين العميل في جدول “oauth_clients”.
للتوجيه في الاتجاه الصحيح، يمكن أولاً التحقق من الإعدادات في ملفات التكوين المختلفة المتعلقة بـ Passport، مثل “config/auth.php” و “config/passport.php”، للتأكد من تكوينها بشكل صحيح وفقًا لمتطلبات التطبيق.
ثم، يجب التحقق من كيفية استخدام Middleware وتكوينه في ملفات التوجيه (مثل “web.php” و “api.php”)، والتأكد من تعيينه بشكل صحيح لكل مسار.
بالإضافة إلى ذلك، يجب التحقق من العميل الذي تم إنشاؤه في جدول “oauth_clients”، والتأكد من أن جميع التفاصيل اللازمة موجودة بشكل صحيح، بما في ذلك “client_id” و “client_secret”، وأنها متطابقة مع البيانات التي تم استخدامها في طلب الوصول.
في حال استمرار المشكلة، قد يكون من الضروري فحص سجلات الخطأ للعثور على أي رسائل خطأ مفيدة، والتي قد تساعد في تحديد مصدر المشكلة بشكل أدق.
باختصار، يتطلب حل هذه المشكلة فحصًا شاملاً لإعدادات Passport واستخدام Middleware وتكوين العميل، بالإضافة إلى تحليل الرسائل الخطأ وسجلات الخطأ، لتحديد الخطوة التالية لحل المشكلة وجعل واجهة البرمجة التطبيقية تعمل بسلاسة.
