Apicurio-studio: مخططات الأمان: لا شيء وآخر (Apikey ، Bearer ...) في نفس الوقت

سأضطر إلى النظر في مواصفات OpenAPI لمعرفة ما إذا كانت هناك طريقة للتعبير عما وصفته. أنا بصراحة لست متأكدا من أعلى رأسي.

بالنسبة لتعطيل مشكلة التحقق من الصحة - لا توجد حاليًا ميزة مطبقة لمنع مشاكل التحقق من الصحة. ومع ذلك ، كان القصد دائمًا هو أن تكون قادرًا على القيام بذلك. لذلك سأعطي الأولوية لهذه الميزة.

يجب أن أضيف أن تنفيذ منطق التحقق قد تم تصميمه ، من البداية ، لدعم تمكين / تعطيل القواعد الفردية. الشيء الوحيد المفقود هو دعم ذلك في واجهة المستخدم. :)

OKelaugier - بعد تفعل شيئا من البحوث حول هذا، والمواصفات OpenAPI لا تدعم في الواقع حالة الاستخدام، ولكن Apicurio لا حقا. إذا كنت مهتمًا بتفاصيل المواصفات ، فإليك بعض المراجع:

https://github.com/OAI/OpenAPI-Specification/issues/14#issuecomment -297457320
https://github.com/OAI/OpenAPI-Specification/issues/1684

لذلك أنا أصنف هذا على أنه خطأ Apicurio وسأفكر في الطريقة المناسبة لدعم حالة الاستخدام هذه في واجهة المستخدم.

شكرا للفت إنتباهي.

ملاحظة للمنفذين المستقبليين (أي أنا): يمكن التعبير عن المصادقة "المجهولة" في مواصفات OpenAPI بتضمين متطلبات أمان فارغة. مثل هذا (على سبيل المثال):

security: [
  {},
  {"oauth": […]}
]

قد يشير هذا إلى أن OAuth يعد خيارًا ، ولكن "لا يوجد مصادقة" يعد أيضًا خيارًا. عادةً في حالة الاستخدام هذه ، تختلف النتائج التي يتم إرجاعها بواسطة API إذا تم إجراء الاستدعاء من خلال المصادقة مقابل بشكل مجهول.

أخبار جيدة! يسعدني أن أكون قادرًا على تقديم مساهمتي الصغيرة جدًا في هذا المشروع. لقد بدأت للتو في استخدامه ويبدو لي أنه أحسنت بشكل خاص. يسمح لك حقًا بالذهاب بشكل أسرع لتحديد واجهة برمجة التطبيقات. شكرا لك على ذلك. إذا وجدت شيئًا آخر (خطأ أو اقتراح) ، فلن أتردد في إخبارك .... شكرًا لك على الإجابة على سؤالي.

نعم من فضلك افعل - أفضل طريقة لجعل مثل هذه المشاريع أفضل هي ردود الفعل من المستخدمين!

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

بالمناسبة elugier - هذا مباشر الآن على https://studio.apicur.io/ - نرحب بالتعليقات. :)

يعمل بشكل جيد! شكرا لك!