Hello. I need to display password protected Discourse feed on the external site. How to do that?
Other sites suggest using this structure http://[username]:[password]@[domain]/[path]
But for Discourse it doesn’t work.
By the way, the external site that I want to show the feed is a wordpress page. Discourse is linked to this page with SSO.
Any ideas?
I assume you mean RSS feeds.
You can generate an API key for a user account on your site in the admin section. Then you can just append it to any URL like so:
http://meta.discourse.org/latest.rss?api_key=KEYHERE
I should note there are security issues with making that api key visible to users. If someone has it, they can do anything that the underlying user account can do. It would be much better to fetch the RSS server side using the key then only exposing the resulting feed.
Also, be especially careful not to generate an “All Users” key for this. If someone gets that key they can do anything as any user on your site. So just be extra careful 
Great answer, eviltrout. Thank you very much
We are having the issue that the RSS feeds do not work with an api_key if the categories have read restrictions, even if the api_key is valid for a user that should be able to access the category.
Is this a bug or by design?
That sounds like a bug to me. The API key should function as the user associated with it. Are you passing the correct username through too?
No, I’m not passing a username, as I am using a key associated with a user.
If I try in an unauthenticated session:
http://myserver.example.com/latest.json?api_key=my_api_key
I get the results I expect
If I try
http://myserver.example.com/latest.rss?api_key=my_api_key
I get no results.
So unless RSS has some special case of how to use API keys, I think it may be a bug
This was a bug, now fixed via:
With the new fix, I am able to view restricted categories in the RSS feed at …
http://myserver.example.com/c/my_category.rss?api_key=my_api_key
but Latest only shows public topics in the RSS feed
http://myserver.example.com/latest.rss?api_key=my_api_key
Is this still unresolved or am I missing something? Thanks.
ألا يجب أن تكون مفاتيح API في الرؤوس الآن يا @sam؟
نعم، يفعلون ذلك! @blake، هل لديك أي أفكار حول كيفية قيام الأشخاص ببناء خلاصات RSS خاصة في العالم الحالي؟ هل تدعم المتصفحات أو برامج قراءة خلاصات RSS رؤوسًا مخصصة للمصادقة؟
هذه حالة استخدام نادرة إلى حد ما، لكن سيكون من الجيد لو وجدنا حلاً بديلاً.
العنصر الوحيد المتعلق بالمصادقة في RSS هو دعم المصادقة الأساسية المعتمدة على عنوان URL مثل https://user:password@www.example.com (وهو ما لا ندعمه حاليًا) أو شيء مشابه لما نوفره حاليًا عبر api_key و api_username في عنوان URL.
بينما كان من الممكن أن يكون من الرائع التخلي تمامًا عن المصادقة المعتمدة على عناوين URL، أعتقد أن المسار الصحيح للحفاظ على دعم خلاصات RSS الخاصة هو السماح بهذا النوع من المصادقة فقط لخلاصات المواضيع والفئات، ثم يمكننا لاحقًا إضافة دعم مفاتيح API للقراءة فقط.
المشكلة تكمن أيضًا في أن قارئات RSS عادةً ما تحتوي على حقل عنوان URL واحد فقط لإضافة الخلاصة، لذا حتى لو كان RSS يدعم الرؤوس (headers)، فإن القارئات لا تملك مكانًا لإضافة بيانات الاعتماد إلى رأس معين.
هنا فكرة واحدة مرتبطة ببعض أعمال تحديد النطاق التي قام بها @david، وهي أن يمكننا إنشاء مفتاح API للمستخدم يكون محددًا بدقة لخلاصة RSS واحدة، مما يقلل من مساحة الهجوم. وفي الحالات التي يكون فيها لدينا مفتاح API للمستخدم محدد بدقة فائقة، يمكننا السماح باستخدامه دون رؤوس (headers)، وذلك عبر إضافة عمود في جدول user_api_key يشير إلى أن هذا المفتاح يمكن استخدامه للمصادقة عبر طلبات GET.
التحديات هنا هي:
لا نملك آلية للمستخدمين لتوليد مفاتيح API الخاصة بهم، وسيتعين علينا بناء شيء ما لحالة استخدام RSS، مما يتطلب واجهة مستخدم جديدة، ولا أعرف حتى أين يمكن إضافتها، ربما في ملف المستخدم، لكنني لست متأكدًا.
لا نملك آلية لتحديد النطاق بدقة لتشمل خلاصة RSS واحدة فقط، وهو ما سيتعين علينا إضافته.
لا نملك معلمة (flag) تشير إلى “مفتاح API للمستخدم المسموح به” عبر معلمات GET في عنوان URL، وهو ما يُعد ضروريًا لهذا الغرض.
بشكل عام، أرى أن هذا شيء يمكننا حله، لكننا على الأرجح نحتاج إلى أسبوع أو أسبوعين من العمل لجعله يعمل بشكل مثالي.
الميزة الإيجابية هي أن بعض هذا العمل هو عمل نرغب في القيام به بغض النظر عن RSS، لكن العيب هو أن بعض العمل مرتبط ارتباطًا وثيقًا بـ RSS، وهناك عدد قليل جدًا من الأشخاص الذين يستخدمون هذه الميزة في الوقت الحالي.
الأمر متروك لـ @codinghorror لاختيار كيفية إعطاء الأولوية لهذا الأمر.
لقد قمت بدمج WordPress مع Discourse، حيث يقوم WordPress بإجراء SSO. أقوم بإنشاء شريط جانبي للمشاركات الأخيرة في WordPress باستخدام خلاصات RSS من عدد من الفئات عبر واجهة برمجة التطبيقات، لذا سأكون سعيدًا جدًا بالحفاظ على آلية مصادقة URL لذلك. وإلا فسأضطر إلى التدخل يدويًا لكتابة عنصر واجهة مخصص لمحاولة تنفيذ خيار مصادقة الرأس. لذا، أعتقد أنني مؤيد واحد من بين القليل من الأشخاص الذين يستخدمون هذه الميزة.
هل يمكن لأحد أن يخبرني ما إذا كان هذا مدعومًا حاليًا أم لا؟
أنا أواجه صعوبة في جعله يعمل.
عندما أحاول استخدام API_KEY في سلسلة الاستعلام، أحصل على الرسالة التالية:
ليس لديك إذن لعرض المورد المطلوب. اسم مستخدم واجهة برمجة التطبيقات أو المفتاح غير صالح.
وهو ما يوحي بأنه يحاول قراءة سلسلة الاستعلام على الأقل.
تحديث:
حسنًا، لقد نجحت في جعل هذا يعمل بشكل جزئي. يبدو أن مجموعة فرعية من تغذيات RSS متاحة، ولكن ليس جميعها؟ عند النظر إلى إعدادات مفتاح واجهة برمجة التطبيقات، يبدو أننا نستطيع الوصول إلى:
قراءة
/t/:slug/:topic_id.rssقراءة القوائم
/c/*category_slug_path_with_id.rss/top/all.rss/top/yearly.rss/top/quarterly.rss/top/monthly.rss/top/weekly.rss/top/daily.rssهل يعرف أحد السبب الذي يجعل هذا يستبعد /latest.rss و /top.rss الأساسي؟
يبدو أن جلب الـ RSS باستخدام مفتاح API يتطلب تحديد رأس قبول (accept header) لاسترداد البيانات الصحيحة.
curl https://bbs.example.com/c/cat.rss?api_key=KEY، فقد يؤدي ذلك إلى ظهور صفحة < HTTP/1.1 404 Not Found.curl 'https://bbs.example.com/c/cat.rss?api_key=KEY' \
-H 'application/xhtml+xml' \