هل تعتقد أنه سيكون من المنطقي تخطي نصوص detect-browser البرمجية عندما يستخدم شخص ما نقطة النهاية التالية:
https://sitename.com/user-api-key/new
من المرجح أن تتم إعادة توجيههم إلى هناك من تطبيق، لذا فإن التحقق مما إذا كانت محرك جافاسكريبت الخاص بهم على ما يرام لا معنى له ويمنع فقط المستخدمين الذين يرغبون في إنشاء مفتاح واجهة برمجة تطبيقات للاستخدام داخل التطبيق.
نعم، هذه هي المشكلة، عندما يقوم user-api-key/new بإعادة توجيهك إلى صفحة تسجيل الدخول، فإنه يبدأ بعد ذلك في فحص متصفحك وبدلاً من السماح بتسجيل الدخول لإنشاء مفتاح واجهة برمجة التطبيقات، فإنه يشتكي من أن متصفحك قديم جدًا، ربما تخطي هذه الفحوصات إذا كان المستخدم هنا فقط لإنشاء مفتاح واجهة برمجة التطبيقات؟
نعم هذه هي المشكلة، إنها نوع من طلب طريقة تسجيل دخول بدون جافاسكريبت، وهذا معقد للغاية نظرًا للكم الهائل من خيارات المصادقة التي ندعمها وإجراءات منع البريد العشوائي.
لا يحتاج الأمر إلى أن يكون بدون جافاسكريبت، فنماذج تسجيل الدخول لا تحتاج حقًا إلى كل الأجراس والصفارات المستخدمة في أماكن أخرى على الموقع؟ على الأقل بالنسبة للمرور إلى auth/oauth2_basic لا يبدو أنه ضروري حيث يتم إنجاز 99٪ باستخدام رؤوس وإعادة توجيه. لدي تطبيق على SailfishOS يعمل بشكل جيد تمامًا مع ملفات .json وتمرير مفتاح api، وهو أمر رائع لأن المتصفح هناك يعتمد على esr78 firefox ويتم حظره في معظم مثيلات discourse، ولكن الطريقة الوحيدة للحصول على مفتاح api تبدو هي إدخال عنوان URL المكون من 200+ حرف يدويًا على سطح المكتب، ثم لصق الرمز الناتج مرة أخرى على الهاتف لفك تشفيره، وهو أمر سخيف للغاية.
مرحباً يا رفاق. كنت أستخدم مفاتيح واجهة برمجة تطبيقات المستخدم لتسجيل الدخول باستخدام عميل طرف ثالث. لقد كان يعمل بشكل جيد. ولكن الآن أحصل على رسالة خطأ في بعض المواقع
الرسالة هي
عفوًا
واجه البرنامج الذي يدعم منتدى المناقشة هذا مشكلة غير متوقعة. نعتذر عن الإزعاج.
تم تسجيل معلومات مفصلة حول الخطأ، وتم إنشاء إشعار تلقائي. سنلقي نظرة عليه.
لا يلزم اتخاذ أي إجراء آخر. ومع ذلك، إذا استمرت حالة الخطأ، يمكنك تقديم تفاصيل إضافية، بما في ذلك خطوات إعادة إنتاج الخطأ، عن طريق نشر موضوع مناقشة في فئة ملاحظات الموقع.
هل كان هناك تغيير في هذه الميزة في الإصدارات الأخيرة؟