ترفض عملية API برسالة Resource not accessible by integration

افهم الأسباب المحتملة

• قد تحتاج العملية قدرة غير موجودة في الأذونات الفعلية أو تستهدف مورداً خارج نطاق الرمز أو تقيدها سياسة الحدث والمؤسسة. ينبغي تحديد هذه الاحتمالات قبل اختيار علاج.
• قد يصل اعتماد إلى github.token ضمنياً، وقد يختلف تمرير أسرار المستدعى أو اختيار بيئته. يمكن لاستبدال كل الرموز باعتماد شخصي واسع عبور حد ثقة منع العملية الأصلية بصورة صحيحة.

حدد العملية المرفوضة بدقة

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

راجع التصريحات والقيود الموروثة

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

قارن المسؤولية بالقدرة

يسأل النموذج المحلي هل تغطي القدرات المعلنة المهمة. لا يحدد تفويض GitHub الحقيقي ولا يفحص رمزاً. يجعل سؤال المراجعة ملموساً: أي مهمة موثوقة تملك العملية المرفوضة، وما أقل قدرة تلزمها إن كانت مخولة أصلاً؟ لا تتجاوز إلى grant قبل حسم هذا الشرط. يتطلب الواقع أيضاً تحقق المورد وسياسة الحدث ونوع الرمز. نجاح المقارنة التعليمية ليس تجربة API، ورفضها يوجه إلى متطلب مفقود في النموذج فقط.

tasks = {"read-source": {"contents:read"}, "publish-release": {"contents:write"}}
granted = {"contents:read"}
for name, required in tasks.items():
    print(name, required <= granted)

read-source True
publish-release False

أبق التحقق غير الموثوق مقيداً

إذا افتقد ناشر موثوق قدرة مشروعة فراجع منحها الضيق له وحده. إذا حاول اقتراح غير موثوق فعلاً مميزاً فافصل العملية بدلاً من منحه السلطة. وإذا خرج المورد عن نطاق GITHUB_TOKEN فاختر هوية مناسبة مصرحاً بها عبر مسار الأمن ولا تضمّن سراً شخصياً. تحقق من وجود السر دون طباعته، وراجع اختيار أسرار البيئة قبل توسيع نطاق القيمة. ينبغي أن يعالج الإصلاح العلاقة الخاطئة المحددة، لا أن يلغي كل القيود حتى تختفي رسالة الرفض.

امنع تكرار المشكلة

• وثق مبرر الأذونات لكل مهمة وقلل سلطة الرمز الضمنية وراجع الثقة عند إضافة API. أظهر ملكية الموارد وعقود أسرار المشاركة. افهم الرفض المتكرر كمسألة تصميم قبل write-all أو اعتماد طويل العمر.