مرحبًا،
لقد حاولت الحصول على مستخدم باستخدام المعرف الخارجي وفقًا للوثائق:
https://docs.discourse.org/#tag/Users/paths/~1u~1by-external~1{external_id}.json/get
لكن النتيجة دائمًا “404 غير موجود” بغض النظر عن المستخدم الذي أجربه. باستخدام نفس الرابط ومفتاح API واسم المستخدم، أستطيع الحصول على التصنيفات والمجموعات بنجاح. هل لديك أي اقتراحات؟
تحياتي،
مارك بيمبيرن
بلو أوشن آيدياز
@pfaffman لا أفهم ردك، فهو لا يحتوي على إجابة. يوضح ذلك الموضوع كيفية اكتشاف نقاط النهاية غير الموثقة. أما هذه النقطة فهي موثقة، وهي واحدة من المكالمات النادرة جدًا في واجهة برمجة التطبيقات التي لا يمكن عكسها هندسيًا بهذه الطريقة، حيث إن نقطة نهاية واجهة برمجة التطبيقات المحددة هذه لا يتم استدعاؤها أبدًا من قبل واجهة Ember الأمامية؟
@mpemburn يجب أن يعمل، فالتوثيق يبدو صحيحًا. المعرف الخارجي هو المعرف في قاعدة بياناتك البعيدة، والذي يتم تمريره عند تمكين الدخول الموحد (SSO). هل يمكنك مشاركة الكود الخاص بك؟
آسف. في أغلب الأحيان، تكون الإجابة على سؤال “توثيق API معطل، كيف يمكنني…” هو ما قمت بالربط إليه. عند النظر بعمق، يصبح من الواضح بشكل مؤلم أن شيئًا ما يتضمن معرفات خارجية لا يمكن الوصول إليه عبر واجهة المستخدم. لحسن حظ مارك أنك تولي اهتمامًا أكبر!
النظرية الأولى:
في معظم الأحيان (وليس دائمًا)، يكون المعرف الخارجي هو معرف قاعدة بيانات، وبالتالي يكون قيمة رقمية. هل أنت متأكد من أن معرفك الخارجي هو mark89؟ هل تُرجع الدالة SingleSignOnRecord.find_by(external_id: 'mark89') سجلًا في قاعدة البيانات؟
النظرية الثانية:
موقعك التجريبي لا يحتوي على تفعيل الدخول الموحد (SSO)، وهو ما يرتبط عادةً بوجود معرفات خارجية. هل أنت متأكد من وجود معرفات خارجية؟
انتظر… رؤوس الطلبات الخاصة بك موجودة في ملف تعريف ارتباط (cookie)؟ هذا غير مقبول… يجب أن يكون الأمر على هذا النحو:
curl --location --request GET 'https://discourse.example.com/u/by-external/mark89.json'
--header 'Accept: application/json'
--header 'Api-Key=[Api-Key]'
--header 'Api-Username=system'
آه، للأسف، هذا لا يعمل أيضًا.
لقد جربت نفس الطلب باستخدام إضافة Discourse الخاصة بـ WordPress، لكنه لا يعمل معها أيضًا، على الرغم من أن طلب الحصول على مستخدم عبر البريد الإلكتروني يعمل. وبما أنني أعتقد أن المشكلة قد تكون في نسخة الـ Sandbox الخاصة بنا من Discourse (وهي النسخة التي كنت أختبر عليها حتى الآن)، فقد جربت الأمر على النسخة الإنتاجية، وكانت القصة نفسها. لست متأكدًا مما يجب فعله بعد الآن، لكنني أحتاج حقًا إلى أن يعمل هذا.
مارك
هل تفحصت نظريتي اللتين كتبتُهما قبل أن أرى أنك ترسل رؤوس المصادقة بالطريقة الخاطئة؟
النظرية الأولى:
في معظم الأحيان (وليس دائمًا)، يكون المعرف الخارجي هو معرف قاعدة بيانات، وبالتالي قيمة رقمية. هل أنت متأكد أن معرفك الخارجي هو mark89؟ هل يعيد SingleSignOnRecord.find_by(external_id: 'mark89') سجلًا من قاعدة البيانات؟
النظرية الثانية:
موقعك التجريبي لا يدعم SSO، وهو ما يرتبط عادةً بالمعرفات الخارجية. هل أنت متأكد من وجود المعرفات الخارجية؟
ريتشارد،
حسنًا، إذًا بيئة الاختبار (sandbox) لا تحتوي على إعدادات الدخول الموحد (SSO)، بينما بيئة الإنتاج تحتوي عليها. لقد تحققت من سجل المستخدم الخاص بي في بيئة الإنتاج، ونعم، تم تعيين المعرف الخارجي (external ID)، وهو في الواقع معرف رقمي. عندما اختبرت باستخدام بيانات اعتماد بيئة الإنتاج وURI والمعرف الخارجي الحقيقي، فقد أعاد نفس خطأ 404.
أوه، وأنا لست متأكدًا من كيفية اختبار SingleSignOnRecord.find_by(external_id: 'mark89'). أين توجد هذه الميزة؟
مارك
cd /var/discourse
./launcher enter app
rails c
SingleSignOnRecord.find_by(external_id: 'mark89')