أجد أن القيمة الافتراضية لـ allowed_user_api_auth_redirects وهي “discourse://auth_redirect” مقيدة للغاية، خاصةً لأن “discourse” لا تبدو كطريقة URI صالحة.
يرجى شرح المنطق وراء هذه القيمة الافتراضية. شكرًا لك.
أواجه هذه المشكلة أيضًا. إذا قمت ببدء استدعاء API من تطبيق JavaScript، فإن رؤوس الترويسة المسموح بها تكون تلقائيًا: User-Api-Key و User-Api-Client-Id، حتى لو لم أكن بحاجة إلى مفاتيح API للمستخدم. كل ما أريده هو مفتاح API بسيط، لكن لا أستطيع جعل أي شيء يعمل. إذا حاولت تمرير Api-Key في الرؤوس، أحصل على خطأ CORS لأنه يتوقع User-Api-Key. لكن عند محاولة استخدام User-Api-Key، أحصل على أخطاء 403. أنا عالق. أعتقد أن هذا هو الاستخدام الأساسي لاستخدام واجهات برمجة التطبيقات. أنا لا أحاول فعل أي شيء غير عادي. أنا ببساطة أحاول إنشاء منشور موضوع جديد.
إعجابَين (2)
هذا هو مخطط URI المخصص الذي تستخدمه تطبيق DiscourseHub لنظامي iOS و Android.
6 إعجابات
لديّ سؤال بخصوص “رموز القراءة” و"رموز الكتابة". هذا التعليق هنا من عام 2016، لذا ربما تم تغييره بالفعل؟ أم أن الإعدادات الافتراضية لا تزال تقتصر على “رموز القراءة” فقط؟
الخلفية: أنا أحد المبرمجين وراء نظام تواصل اجتماعي موزّع. لدينا بالفعل موصلات لأنظمة غير موحدة. الفكرة هي كتابة إضافة لـ Discourse أيضًا. لكن نظرًا لأن معظم الأنظمة على الأرجح لن تسمح للمستخدمين بإنشاء رموز تسمح بالنشر، سنحاول طريقة أخرى. لدينا بالفعل موصل للبريد الإلكتروني. ثم سنستخدم ببساطة وظيفة قائمة البريد في Discourse، وسنحاول تحسين المحتوى المعاد، وسننشر عبر SMTP.
يمكنك كتابة الرموز إذا طلبت النطاق مسبقًا
3 إعجابات
بالطبع، هذا ممكن دائمًا. لكنني أشعر بأن هذا قد يتحول إلى كابوس للدعم الفني. يحتوي برنامجنا على مئات التثبيتات مع أكثر من 10 آلاف مستخدم في المجموع. عندما يرون أن هناك إضافة تتصل بـ Discourse، فسيكون الكثير منهم حتمًا راغبين في استخدامها. وبما أنها على الأرجح لن تعمل مباشرة من الصندوق، فإن هذا سيولد أسئلة وعمل دعم من جانبنا. بالإضافة إلى ذلك، سيولد ذلك عملًا لمسؤولي تثبيتات Discourse المختلفة. وعلى الأرجح لن يسمح الجميع بذلك، مما سيسبب الإحباط.
لذلك، ربما سأركز في البداية على دمج رسائل وضع القائمة البريدية. أم هل من الممكن الجمع بين هذين الأمرين؟ أعني: قراءة المنشورات عبر واجهة برمجة التطبيقات (API)، ولكن النشر عبر بروتوكول SMTP؟
مرحبًا… لا أعرف كيفية توليد public_key. هل يجب أن أستخدم مولد RSA للحصول على المفتاح العام/الخاص؟
إذا كان الأمر كذلك، فقد استخدمت بعض مولدات RSA عبر الإنترنت، لكنني أواجه هذا الخطأ:
OpenSSL::PKey::RSAError (Neither PUB key nor PRIV key: nested asn1 error) /var/www/discourse/app/controllers/user_api_keys_controller.rb:189:in `initialize'
أيضًا، أود أن أسألكم إذا كان هذا يناسب حالتي الاستخدام:
لدي تطبيق، وأريد بشكل أساسي مصادقة المستخدم والحصول على اسم المستخدم. هل تدفق إنشاء مفتاح API هو التدفق الأبسط للتحقق من تسجيل دخول المستخدم في تطبيقي؟ إذا أمكن، أود تجنب SSO لأنه يبدو أكثر تعقيدًا.
أنا في نفس القارب، رغم أنني أحاول فقط استخدام User-Api-Key (وليس Api-Key) لإنشاء منشور موضوع وأواجه رفض CSRF من مكتبة actionpack.
ما لم يكن خادم Discourse قد عطل فحص CSRF، يبدو أن النشر من تطبيق سطح مكتب تابع لجهة خارجية أمر صعب. ولا أخطط لمحاكاة متصفح.
@sam ما رأيك في السماح بمفاتيح واجهة برمجة التطبيقات الخاصة بالمستخدمين التي تحتوي فقط على نطاق read، بأن تُمرَّر عبر معاملات URL في طلبات GET؟
الحالة الاستخدامية هي تمكين التكاملات مثل الاشتراك في العلامات المحسّنة مع التذكيرات في تقويم جوجل باستخدام مفاتيح واجهة برمجة التطبيقات الخاصة بالمستخدمين.
5 إعجابات
ما رأيك في إنشاء نطاق جديد محدد، مع معلمة ثالثة للإشارة إلى “معامل GET مسموح به”. بهذه الطريقة، لا يمكن للأشخاص إساءة استخدامه لأغراض أخرى (مثل تجاوز CORS وطلب واجهة برمجة تطبيقات Discourse من موقع آخر).
(من هنا)
SCOPES = {
read: [:get],
write: [:get, :post, :patch, :put, :delete],
message_bus: [[:post, 'message_bus']],
push: nil,
one_time_password: nil,
notifications: [[:post, 'message_bus'], [:get, 'notifications#index'], [:put, 'notifications#mark_read']],
session_info: [
[:get, 'session#current'],
[:get, 'users#topic_tracking_state'],
[:get, 'list#unread'],
[:get, 'list#new'],
[:get, 'list#latest']
],
+ calendar: [ [:get, 'users#bookmarks_cal', true ] ],
}
(ملاحظة جانبية: لماذا نستخدم مصفوفات متداخلة هنا…)
10 إعجابات
أعجبني أن مفتاح API سيتم تحديده صراحةً على أنه “مسموح به في GET” على مستوى المستخدم.
بشكل عام، يمكن أن تكون الخيارات مفتوحة لأي طلبات GET. القاعدة التي أعجبني هي، عند العمل في هذا الوضع:
- مفتاح API الخاص بالمستخدم مقيد بنسبة 100% بإجراء تحكم GET واحد محدد
- يُشار إلى مفتاح API الخاص بالمستخدم على أنه مسموح به في معاملات استعلام GET.
هذا يحد من تأثير أي تسرب هنا عبر وكيل، لأن المفتاح لن يُعاد استخدامه أبدًا.
أعتقد أن {get: 'list#new'} , {get: 'list#latest'} سيعمل أيضًا.
7 إعجابات
أنا مهتم جدًا بمفاتيح واجهة برمجة التطبيقات للمستخدم من نوع ‘get param only’. سؤالي هو: هل تخططون للسماح للأشخاص بإنشاء هذه المفاتيح عبر واجهة المستخدم؟
ربما، ربما يكون ذلك خلف إعداد موقع أو عبر إضافة. نحن نخطط لتوحيد مجموعة الميزات قليلاً بحيث تدعم مفاتيح واجهة برمجة التطبيقات الخاصة بالمسؤول أيضًا النطاقات.
4 إعجابات
مرحبًا.. هل يمكنك حل هذه المشكلة؟ لدي نفس المشكلة ولم أستطع إصلاحها. لقد جربت تمرير أنواع مختلفة من المفاتيح ولكن لا شيء نجح. أي مساعدة ستكون موضع تقدير كبير.
هل توجد مكتبات لهذا الغرض؟ وإذا لم تكن موجودة، هل هناك مثال على التطبيق؟ أحاول استخدام PHP لتحديد حساب المستخدم في Discourse في جزء منفصل من الموقع. يبدو أن هذا تدفق OAuth معدل، لكنني مشوش قليلاً بشأن كيفية تنفيذه.
على وجه التحديد، لست متأكدًا من كيفية إجراء عملية توليد المفاتيح العامة والخاصة بالكامل.
هل توجد طريقة للقيام بـ OAuth 2 فقط مع Discourse كمزود OAuth؟
إعجابَين (2)
هل نجحت في ذلك باستخدام مفتاح API الخاص بالمستخدم؟ أنا أيضًا أحصل على رسالة “غير مصرح لك بعرض المورد المطلوب”
إعجاب واحد (1)
لقد اكتشفت الخطأ الذي ارتكبته: الحمولة المُرجعة ليست مفتاح UserAPI نفسه، بل هي سلسلة JSON مشفرة، ويتطلب فك تشفيرها استخدام المفتاح الخاص من زوج المفاتيح الخاص/العامة.
إعجابَين (2)
تعديل: تمكنت من جعل معظمه يعمل، وسأقدم وصفًا بمجرد أن أتمكّن من تشغيله بالكامل.
كيف يحصل العميل على زوج المفاتيح الخاص/العام والمعرف؟
هل يمكنك توفير كود للحصول على مفتاح API للمستخدم باستخدام تطبيق جافا سكريبت؟ (تطبيق جافا سكريبت يحاول السماح للمستخدم بإجراء مكالمات API إلى منتدى Discourse).
أحصل على أخطاء 403. أو خطأ يقول: عذرًا، لا يمكننا إصدار مفاتيح API للمستخدمين، وقد يكون هذا الميزة معطلاً من قبل مدير الموقع (على الرغم من أن موقعي قد فعل خيار: السماح بتوليد مفاتيح API للمستخدمين).
أعتقد أن المشكلة قد تكون في كيفية توليد زوج المفاتيح الخاص/العام (كيف يتم ذلك؟)، ثم معالجة إعادة التوجيه.
أي كود سيكون موضع تقدير.
تمكنت من جعل هذا يعمل بعد بعض التجربة والخطأ.
إليك الخطوات الأساسية التي أتبعها عندما يكون لدي تطبيق منفصل قمت ببرمجته، وأريد أن يتمكن المستخدمون من استخدام هذا التطبيق لإجراء استدعاءات API إلى موقع Discourse.
لنفعل ذلك، أحتاج إلى إنشاء رمز API خاص بكل مستخدم لإجراء الاستدعاءات نيابة عن كل مستخدم محدد (على الأقل في بيئة Node.js/JavaScript).
ملاحظة: بالنسبة لجهة JavaScript، وجدت أن الكود الذي قدمه @KengoTODA هنا مفيد جدًا: discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub
إليك الخطوات التي اتبعتها:
أولاً: توليد زوج من المفاتيح العامة والخاصة.
هذا شيء يجب أن يولده تطبيقك — مفتاح عام ومفتاح خاص. توفر ملخص GitHub (Gist) طريقة واحدة للقيام بذلك.
ثانياً: وجود عنوان URL لإعادة التوجيه.
هذا هو عنوان URL الذي سيعيد Discourse التوجيه إليه، مع توفير رمز API النهائي في الحمولة (payload). إذا كان لديك تطبيق سطح مكتب (أي لا يحتوي على عنوان URL للمتصفح)، فسيكون عنوان URL لإعادة التوجيه قائمًا على بروتوكول مخصص قمت بإعداده لفتح التطبيق عند إدخال عنوان URL لإعادة التوجيه في المتصفح.
لاحظ أن عنوان URL لإعادة التوجيه يجب أن يُدرج في القائمة البيضاء في إعدادات الموقع لموقع Discourse المستهدف.
كما يحتاج موقع Discourse على الأرجح إلى تفعيل إعداد الموقع “السماح بمفاتيح API للمستخدمين”. راجع المنشور الأصلي في هذا الموضوع بخصوص “إعدادات الموقع”.
ثالثاً: إرسال استدعاء طلب API إلى عنوان URL لطلب Discourse.
لذا، سيقوم تطبيقك بإرسال استدعاء إلى عنوان URL يتبع هذا الشكل:
https://[your target discourse site .com]/user-api-key-new"
مع إضافة المعاملات التالية:
- اسم تطبيقك
- “client_id” الخاص بك (تمكنت من استخدام hostname()، من
const {hostname} = require('os')لتطبيق سطح المكتب، تمامًا كما في ملخص GitHub المشار إليه أعلاه) - النطاقات (scopes) (هذه هي النطاقات التي تريد أن يتمكن المستخدم من القيام بها عبر API، مثل “write”، “read”، إلخ)
- مفتاحك العام (من الخطوة 1 أعلاه)
- عنوان URL لإعادة التوجيه الخاص بك (من الخطوة 2 أعلاه)
- nonce (هذه قيمة يمكنك اختيارها — يبدو أن استخدام ‘1’ فقط يعمل)
رابعاً: موافقة المستخدم على تطبيقك في صفحة موقع Discourse التي يتم فتحها بواسطة عنوان URL للطلب.
عند إرسال عنوان URL للطلب بنجاح، يفتح صفحة على موقع Discourse تخبر المستخدم بأن تطبيقك يريد الوصول إلى الموقع.
في تلك الصفحة، يوجد زر يسمح للمستخدم بالموافقة. عند النقر على هذا الزر، يعيد موقع Discourse التوجيه إلى عنوان URL لإعادة التوجيه الذي قدمته، ويضيف كمعامل ?payload=[the API KEY]. مفتاح API هنا هو المفتاح الذي تحتاج إلى فك تشفيره في تطبيقك.
خامساً: يلتقط تطبيقك قيمة عنوان URL لإعادة التوجيه (مع قيمة الحمولة)، وتقوم بفك تشفير مفتاح API.
لقد اقتربت من النهاية. يحتاج تطبيقك إلى تحليل عنوان URL لإعادة التوجيه الذي انتقل إليه Discourse، والحصول على مفتاح API الموجود في الحمولة.
بمجرد حصولك على مفتاح API هذا، تحتاج إلى القيام بأمرين:
- احصل على المفتاح الفعلي، وليس النسخة المشفرة URL: إذا كنت تحصل على معامل من عنوان URL، فغالبًا ما يكون مشفرًا URL (إضافة % هنا وهناك، إلخ). تحتاج إلى تنظيفه. في JavaScript، وجدت أن
decodeURIComponentتعمل لهذا الغرض. - بمجرد استلامك لمفتاح API المنقى من Discourse، تحتاج إلى فك تشفيره. للقيام بذلك، يمكنك استخدام فك التشفير في JavaScript باستخدام المفاتيح الخاصة. أساسًا، تستخدم مفتاحك الخاص (المُولد في الخطوة الأولى أعلاه) لفك تشفير مفتاح API المنقى. هناك بعض أمثلة JavaScript في ملخص GitHub الذي أشرت إليه أعلاه: discourse-api-key-generator/src/index.ts at main · KengoTODA/discourse-api-key-generator · GitHub
بعد تشغيل كود فك التشفير، يكون لديك الرمز نفسه، والذي يمكنك الآن استخدامه لإجراء استدعاءات API مصادق عليها نيابة عن المستخدم.
سادساً: استخدم الرمز (أي مفتاح API النهائي، المنقى، وفك تشفيره) لإجراء استدعاءات API نيابة عن المستخدم.
مع هذا الرمز، يبدو أنك لا تحتاج إلى إدخال اسم المستخدم في استدعاء API. أجد أن العنوان التالي كافٍ عند تضمينه في استدعاءات GET أو POST أو PUT، إلخ:
headers: {
"User-Api-Key": [the token]
}
وبذلك، يكون لديك على الأرجح طريقة مصادقة لكل مستخدم تعمل للتفاعل مع Discourse.
7 إعجابات
ما هي الآثار الأمنية لإضافة أشياء إلى allowed_user_api_auth_redirects؟ لدي شخص يطلب إضافة سلسلة نصية لدعم تكامل NextCloud.
إعجاب واحد (1)