Api-blueprint: المصادقة

هذا يبدو مفيد حقا بالنسبة لي.

xurde سعيد لسماع ذلك! إذا كنت ترغب في ذلك ، فلا تتردد في اقتراح بناء جملة أو مجرد مشاركة كعب / مثال لكيفية وصفه. هل أنت مهتم أيضًا بنوع معين من المصادقة؟

سأكون مهتمًا بدعم OAuth 1.1 الذي يتطلب تعيين رأس تفويض HTTP بحقول مختلفة.

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

يستخدم OAuth 2.0 على نطاق واسع.

يُرجى إعلامي ما إذا كانت السمات على النحو المقترح في رقم 47 ستحسن احتياجات المصادقة. راجع أيضًا هذا المثال: https://gist.github.com/zdne/01e287fe18d232672d43#file -4-example-gist-fox-api-md

ليتم معالجتها (وإغلاقها) بالرقم 47.

لست متأكدًا مما إذا كان هذا لا يزال قيد العمل ، ولكن طريقة توثيق أن مفتاح واجهة برمجة التطبيقات مطلوب لجميع الطلبات ستكون رائعة! لذا في مكان ما يمكنني وضع هذا {?apikey} في جميع الطلبات دون الحاجة إلى إضافته يدويًا كمعلمات لجميع المسارات.

مرحبًا searsaw ،
نعم ، هذه هي أولويتنا القصوى - مجدولة مباشرة بعد # 25 (والتي تقترب من نهايتها ، لذا نأمل أن نبدأ بها قريبًا).

سي سي pksunkara

يحتوي مشروع oauthd على معرض رائع من الأوصاف التعريفية لمصادقات OAuth المختلفة لأكثر من 100+ واجهات برمجة تطبيقات إنتاج. ألق نظرة على الملفات conf.json و settings.json في أي مجلد هنا .

أعتقد أنه مصدر إلهام جيد لمتطلبات OAuth في بنية مخطط API.

يقترح بناء الجملة في # 201

تمت إضافة مقترحات RFC إلى OP: https://github.com/apiaryio/api-blueprint/issues/11#issue -18055746

إذن ما هي حالة المصادقة؟ تم إغلاق # 201 ، لأنه تم استبداله بـ https://github.com/apiaryio/api-blueprint-rfcs/pull/5 و https://github.com/apiaryio/api-blueprint-rfcs/pull/6. لقد تم دمجهم كـ RFC منذ أكثر من عامين ، فهل سيتم تنفيذه؟

أي تحديث؟