API تفشل على secondsite، وعملت على primary/default site

أقوم بتقسيم موقع إلى موقعين منفصلين باستخدام طريقة المواقع المتعددة، وهذا يعني أنني أواجه صعوبة مع واجهة برمجة التطبيقات (API) مرة أخرى.

الآن، ما أحاول فعله هو إلغاء تنشيط المستخدمين من القائمة 1 (الموقع الافتراضي) في القائمة 2 (الموقع الثاني).

لقد قمت بالفعل بإلغاء تنشيط المستخدمين في القائمة 2 من القائمة 1، وكل ما غيرته في برنامج PHP الخاص بي هو إنشاء مفتاح API جديد على الموقع الثاني، وإدراجه في استدعاء CURL، وأحصل على أخطاء Invalid_Access.

إليك استدعاء تم تنقيحه (مع إغفال معظم مفتاح API)، وهو صالح لهذا المستخدم فقط وله وصول عام.

curl -X PUT -H "Content-Type: multipart/form-data;" -H "Api-Key: a23..." -H "Api-Username: nolan" "https://nu-sports.tssi.com/admin/users/4/deactivate.json/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0    98    0    98    0     0    212      0 --:--:-- --:--:-- --:--:--  4454
{"errors":["You are not permitted to view the requested resource."],"error_type":"invalid_access"}

ما هي الخلطة السرية التي أفتقدها؟

هل قمت بإنشاء مفتاح واجهة برمجة تطبيقات جديد في الموقع الثاني؟ مثل، المفتاح غير صالح.

نعم، لقد جربت مفتاحين جديدين مختلفين، لم ينجح الأمر.

إذا كان يسجل الخطأ، فأنا لا أرى أين.

يبدو أنه يصل إلى المفتاح الصحيح وفقًا لقائمة واجهة برمجة التطبيقات:
a233… إلغاء تفعيل المشتركين في huskerlist 24x24 قبل 6 ساعات ودقيقة واحدة

إعجاب واحد (1)

حاولت أيضًا إنشاء مفتاح API للمستخدم النظام، نفس الخطأ.

سأجرب مفتاحًا عالميًا ثم أحاول تقليل النطاق.

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

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

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