أعلنت Cloudflare إتاحة ضوابط وصول على مستوى كل Worker، بحيث يمكن منح مستخدم أو وكيل برمجي أو رمز API صلاحية التعامل مع تطبيق محدد دون الوصول إلى بقية الموارد في الحساب. وتأتي الخطوة مع أربعة أدوار جديدة لمنصة المطورين، صممت للفصل بين مراقبة التطبيق وقراءة محتواه وتعديله أو إدارته بالكامل.
الضوابط متاحة لجميع العملاء اعتباراً من 15 سبتمبر 2026، ويمكن إعدادها من لوحة تحكم Cloudflare أو عبر API أو Terraform. كما يمكن تطبيقها على مستخدم منفرد أو على User Group، بحيث يرث جميع أعضاء المجموعة السياسة نفسها.
أربعة مستويات للصلاحيات
- Metadata Read-Only: يتيح الاطلاع على قوائم الموارد وإعداداتها وبيانات المراقبة، مثل المقاييس والسجلات وآثار التتبع، من دون الوصول إلى محتوى المنتج أو الشيفرة. يناسب التحقيق في الأعطال عندما لا تكون قراءة المصدر مطلوبة.
- Content Read-Only: يتيح قراءة محتوى المنتج، مثل شيفرة Worker أو محتوى قاعدة D1، من دون تعديل أو نشر تغييرات.
- Editor: يتيح قراءة المحتوى وكتابته وتحديث الإعدادات، لكنه لا يسمح بإنشاء الموارد أو حذفها. وتطرحه Cloudflare كخيار مناسب لأنظمة CI/CD التي تحتاج إلى نشر تغييرات في Worker محدد.
- Admin: يمنح تحكماً كاملاً في المورد، بما في ذلك الإنشاء وإعادة التسمية والحذف ومنح الوصول لمستخدمين آخرين، مع إمكانية حصر هذه الصلاحية في Worker واحد بدلاً من الحساب بأكمله.
ما الذي يتغير عملياً؟
يمكن لفريق التشغيل منح مهندس أو وكيل صلاحية Metadata Read-Only لفحص الإعدادات والمقاييس والسجلات وآثار التتبع من دون كشف الشيفرة. وبالمثل، يستطيع وكيل مراجعة الشيفرة باستخدام Content Read-Only من دون امتلاك القدرة على نشرها أو تغيير إعدادات التطبيق.
أما في مسارات CI/CD، فيمكن إنشاء رمز API بدور Editor ومقيد بـ Worker واحد. وإذا أسيء إعداد المسار أو انكشف الرمز، تظل قدرته محصورة في نشر تغييرات لذلك التطبيق، من دون حذف Worker أو تعديل تطبيقات أخرى في الحساب. وتوضح Cloudflare أن هذه الصلاحيات تطبق وفق ثلاثة نطاقات: منصة المطورين كاملة، أو منتج معين مثل Workers، أو مورد محدد مثل Worker واحد.
قيود مهمة على النطاق والاتصالات
الوصول إلى Worker لا يكفي وحده لإضافة Route أو Custom Domain أو تغييرهما أو حذفهُما. تتطلب هذه العمليات صلاحية Editor على Worker، إلى جانب إذن Workers Routes الخاص بالمنطقة. ويتيح هذا الفصل إدارة كيفية توجيه الحركة إلى التطبيق من دون منح صلاحيات أوسع على إعدادات النطاق.
بعد إعداد المسار، يستطيع نظام CI/CD مواصلة نشر إصدارات جديدة ما دام النشر لا يغير الاتصال القائم، ومن دون منحه وصولاً إلى النطاقات أو قواعد البيانات أو التخزين المرتبط. كما تعتمد Durable Objects على صلاحيات Worker الذي ينفذها؛ فدور Metadata Read-Only يتيح مقاييسها وسجلاتها وآثارها، لكنه لا يتيح قراءة البيانات المخزنة فيها. ويتطلب الوصول إلى Data Studio، الذي يستطيع الاستعلام عن البيانات وتعديلها، دور Editor.
رسائل أخطاء وإصدارات قديمة
حدّثت Cloudflare استجابات API عند رفض العمليات، بحيث لا تقتصر على الخطأ العام 403 Forbidden، بل تتضمن رابطاً إلى التوثيق الذي يحدد الإذن المطلوب. ويفترض أن يساعد ذلك المستخدمين والوكلاء على ضبط الصلاحيات بدقة بدلاً من توسيعها عشوائياً.
توصي الشركة بالانتقال إلى الأدوار الجديدة بدلاً من الصلاحيات القديمة الخاصة بـ Workers، لكنها لم تعلن موعداً لإيقافها، وستظل التعيينات الحالية تعمل إلى حين تقديم إشعار مسبق. وتخطط Cloudflare لتوسيع النموذج نفسه إلى منتجات أخرى، منها D1 وR2 وKV، بحيث يمكن تقييد الوصول إلى قاعدة بيانات أو مساحة تخزين بعينها.
قراءة certi.news
التغيير الفعلي هنا ليس إضافة دور إداري جديد فحسب، بل نقل التحكم من مستوى الحساب أو المنتج إلى مستوى المورد، مع فصل واضح بين بيانات المراقبة والمحتوى والتنفيذ. وهذا مهم خصوصاً للفرق التي تستخدم وكلاء برمجيين أو خطوط نشر آلية، لأن الخطأ أو تسرب الرمز يمكن احتواؤه ضمن Worker واحد. في المقابل، تظل إدارة المسارات والنطاقات نقطة تحتاج إلى صلاحية مستقلة، كما أن دعم D1 وR2 وKV ما زال مذكوراً كخطة لاحقة لا كإتاحة حالية. أما استمرار الصلاحيات القديمة بلا موعد تقاعد معلن، فيعني أن المؤسسات ستحتاج إلى مراجعة سياساتها تدريجياً بدلاً من افتراض انتقال فوري.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.