أنا مبتدئ تمامًا. أحتاج إلى مساعدة، كيف يمكنني منح حق الوصول إلى discourse عبر API؟
أولاً، قم بإنشاء مفتاح API عن طريق الانتقال إلى المسؤول > متقدم > مفاتيح API، والنقر فوق مفتاح API جديد، وتكوين تفاصيله. ثم استخدم مفتاح API الذي تم إنشاؤه واسم المستخدم للمستخدم الذي تم إنشاؤه من أجله في رؤوس Api-Key و Api-Username لطلبات API الخاصة بك. @Enit
@Enit مرحباً، هل يمكنك تقديم المزيد من التفاصيل حول هذا؟ هل تقصد منح الوصول إلى منتدى خاص عبر واجهة برمجة التطبيقات (API)، أم شيئًا آخر؟
شكراً!
إعجاب واحد (1)
نحن نبني نظام ذاكرة مدعوم بالذكاء الاصطناعي حيث تتفاعل وكلاء الذكاء الاصطناعي المتعددون (DeepSeek، Claude، ChatGPT، إلخ) مع منتدى Discourse الخاص بنا كقاعدة معرفية مشتركة.
الإعداد الحالي:
- منتدى Discourse مستضاف ذاتيًا (أحدث إصدار مستقر)
- خادم افتراضي خاص (VPS): Ubuntu 22.04، تثبيت قائم على Docker
- مستخدم المسؤول:
adminjozsi - مستخدم وكيل الذكاء الاصطناعي:
grokenit(تم إنشاؤه عبر دعوة بريد إلكتروني)
المشكلة
نواجه مشاكل إبطال مفاتيح واجهة برمجة التطبيقات بشكل متكرر:
- تنتهي صلاحية مفاتيح واجهة برمجة التطبيقات بشكل غير متوقع حتى عند تعيينها إلى صلاحية “سنة واحدة”
- تظهر أخطاء “واجهة برمجة تطبيقات غير صالحة” بشكل عشوائي، مما يتطلب إنشاء مفاتيح جديدة
- المفاتيح التي كانت تعمل بالأمس تفشل فجأة اليوم دون أي تغييرات في التكوين
- الخطأ:
{"errors":["Invalid API key"]}عند طلبات POST إلى/posts.json
ما جربناه
مفاتيح واجهة برمجة التطبيقات على مستوى المستخدم (بدلاً من المفاتيح العامة)
- الوصف: “Grok - مفتاح واجهة برمجة تطبيقات المستخدم - adminjozsi”
- مستوى المستخدم: “مستخدم واحد” →
adminjozsi - النطاق: عام
تعديلات حد المعدل:
- تعيين “معدل إنشاء منشورات المستخدمين الجدد” إلى
0 - زيادة جميع حدود المعدل للمستخدمين الجدد
إعادة إنشاء متعددة:
- تم إنشاء أكثر من 5 مفاتيح لواجهة برمجة التطبيقات خلال الأسبوع الماضي
- كل منها يعمل في البداية، ثم يفشل في غضون 24-48 ساعة
أسئلة
1. لماذا تنتهي صلاحية مفاتيح واجهة برمجة التطبيقات على الرغم من إعداد السنة الواحدة؟
هل هناك آلية انتهاء صلاحية مخفية نغفل عنها؟ سجلات الخادم لا تظهر أي أحداث إلغاء.
2. هل يمكن لمفتاحين مختلفين لواجهة برمجة التطبيقات مشاركة نفس رأس Api-Username؟
فكرة بنيتنا:
- مفتاح واجهة برمجة التطبيقات رقم 1 → يستخدمه المسؤول البشري (أنا) للعمليات اليدوية
- مفتاح واجهة برمجة التطبيقات رقم 2 → يستخدمه وكيل الذكاء الاصطناعي (DeepSeek) للمنشورات الآلية
- كلا المفتاحين → نفس رأس
Api-Username: adminjozsi
السؤال: هل سيتعامل Discourse مع هذا بشكل صحيح، أم أنه يتوقع مفتاحًا واحدًا = مستخدم واحد؟
3. هل يجب علينا إنشاء مستخدمين منفصلين لكل وكيل ذكاء اصطناعي؟
نهج بديل:
- المستخدم
adminjozsi→ المسؤول البشري (أنا) - المستخدم
grokenit→ وكيل الذكاء الاصطناعي #1 (DeepSeek) - المستخدم
claude-ai→ وكيل الذكاء الاصطناعي #2 (Claude) - كل منهم بمفتاح واجهة برمجة التطبيقات الخاص به
مخاوف:
- هل تحتاج حسابات وكلاء الذكاء الاصطناعي إلى تعديلات في مستوى الثقة؟
- هل سيؤدي هذا إلى مشاكل في تحديد المعدل؟
- هل هذا هو النمط الموصى به للتكاملات الروبوتية/الوكيلة؟
4. هل هناك أفضل الممارسات لاستقرار واجهة برمجة التطبيقات للاستخدام غير المباشر/الآلي؟
نحن بحاجة إلى مصادقة قوية لواجهة برمجة التطبيقات لأن:
- وكلاء الذكاء الاصطناعي يعملون على مدار الساعة طوال أيام الأسبوع دون إشراف بشري
- المنشورات الفاشلة = فقدان البيانات في نظام الذاكرة الخاص بنا
- إعادة إنشاء المفاتيح تتطلب تدخلًا يدويًا
التفاصيل الفنية
تنسيق طلب واجهة برمجة التطبيقات:
curl -X POST "https://www.enit.hu/posts.json" \
-H "Api-Key: [KEY]" \
-H "Api-Username: adminjozsi" \
-H "Content-Type: application/json" \
-d '{"title":"Test","raw":"Content","category":6}'
يعمل في البداية: يُرجع {"id":123,"topic_id":45,...}
بعد 24-48 ساعة: 
يُرجع {"errors":["Invalid API key"]}
بيئة الخادم:
- إصدار Discourse: 3.6.0.beta2-latest (f26f894bfc)
- تثبيت قائم على Docker
- لا يوجد وكيل عكسي (HTTPS مباشر عبر Let’s Encrypt)
- لا توجد شبكة توصيل محتوى (CDN) أو طبقة تخزين مؤقت
ما نحتاجه
الحل المثالي:
- مفاتيح واجهة برمجة تطبيقات مستقرة لا تنتهي صلاحيتها بشكل غير متوقع
- إرشادات واضحة حول بنية الوكلاء المتعددين (مفتاح واحد مقابل مفاتيح متعددة)
- نصائح استكشاف الأخطاء وإصلاحها لأخطاء “واجهة برمجة تطبيقات غير صالحة” عندما يجب أن تكون المفاتيح صالحة
نقدر أي رؤى! هذا يمثل عائقًا حرجًا لمشروع تكامل الذكاء الاصطناعي الخاص بنا.
عنوان URL للمنتدى: https://www.enit.hu
يسعدنا تقديم المزيد من السجلات/التفاصيل إذا لزم الأمر!
لقد فعلت هذا. تعمل واجهة برمجة التطبيقات لبضع ساعات ثم تتوقف عن العمل.
اسمي جوزيف، أنا من المجر، وأعمل في ورديات ليلية في مصنع.
أنا لست مطورًا أو شخصًا في مجال تكنولوجيا المعلومات، فقط أحاول بناء شيء مفيد لنفسي - نظام صغير للحفاظ على ملاحظاتي العملية والشخصية منظمة.
لقد قمت بتثبيت Discourse على خادم VPS الخاص بي لأنني أردت استخدامه كمفكرة خاصة أو أداة ذاكرة.
إنه ليس عامًا، ولا يستخدمه أي شخص آخر، إنه لي فقط.
أستخدمه مع بعض مساعدي الذكاء الاصطناعي (مثل ChatGPT أو Claude) لكتابة وتنظيم إدخالات قصيرة حول العمل اليومي، أو الزراعة، أو ذكريات العائلة.
يساعدني على تذكر روتين المصنع، وتتبع المشاريع الصغيرة، والحفاظ على تنظيم الأشياء في مكان واحد.
في كل مرة أقوم فيها بإنشاء مفتاح API في لوحة الإدارة، فإنه يعمل لبضع ساعات فقط.
ثم يتوقف فجأة عن العمل ويقول “مفتاح API غير صالح”.
يجب علي إنشاء مفتاح جديد، مما يعطل إعداداتي.
لقد حدث هذا عدة مرات بالفعل في أسبوع واحد.
مفاتيح API على مستوى المستخدم (ليست عامة)
حدود المعدل مضبوطة على 450
تم التحقق من السجلات
تم تجربة إعدادات مختلفة
لا شيء يساعد - يظل المفتاح غير صالح بعد بضع ساعات.
هل هناك طريقة لإنشاء مفتاح API لا تنتهي صلاحيته تلقائيًا؟
أو ربما طريقة مصادقة أفضل لإعداد مستخدم واحد؟
يمكن أن يساعدني إعداد Discourse هذا حقًا في إدارة حياتي العملية والشخصية.
إنه نظام خاص، على خادمي الخاص، بدون مستخدمين عامين - أنا فقط.
إذا أمكن إصلاح مشكلة API هذه، أعتقد أن الآخرين يمكنهم أيضًا استخدام Discourse بهذه الطريقة، ليس فقط للمنتديات ولكن أيضًا كنظام ذاكرة شخصي.
التفاصيل الفنية
-
النطاق: https://www.enit.hu
-
الإصدار: Discourse 3.6.0.beta2-latest
-
الإعداد: Docker على Ubuntu 22.04 LTS
-
VPS: RackForest (2 جيجابايت ذاكرة وصول عشوائي)
-
المستخدم: مسؤول واحد (adminjozsi)
-
لماذا يصبح المفتاح غير صالح؟
-
هل هناك إعداد انتهاء صلاحية مخفي؟
-
كيف يمكنني جعله مستقرًا؟
أقدر حقًا أي مساعدة يمكنك تقديمها.
إذا وجدت حلاً يعمل، فسأكتب بكل سرور دليلًا قصيرًا حتى يتمكن الآخرون في وضع مماثل من استخدامه أيضًا.
شكرًا مرة أخرى،
جوزيف تومكو
https://www.enit.hu