أعلنت Cloudflare عن إضافة تخصيص نطاقات OAuth، وهي ميزة تسمح لمالكي تطبيقات OAuth التابعة لجهات خارجية بتحديد الصلاحيات الإلزامية والاختيارية. وبذلك يستطيع المستخدم، أثناء شاشة الموافقة، إلغاء الصلاحيات الاختيارية ومنح التطبيق نطاقاً أضيق من الوصول بدلاً من الاختيار بين قبول كل الصلاحيات المطلوبة أو رفض الطلب بالكامل.
تأتي الخطوة بعد أن أنشأ المطورون آلاف تطبيقات OAuth التابعة لجهات خارجية على Cloudflare منذ يونيو، مع تسجيل أكثر من مليون عملية تفويض منذ ذلك الحين. وتستخدم هذه التطبيقات في تكاملات البرمجيات كخدمة، والأدوات الداخلية، وواجهات سطر الأوامر، والوكلاء البرمجيين.
من الموافقة الشاملة إلى الصلاحيات المرتبطة بالمهمة
كان Cloudflare OAuth يسمح للتطبيق بطلب مجموعة فرعية من النطاقات التي جرى إعدادها له، لكن المستخدم لم يكن قادراً على تقليص هذه المجموعة من شاشة الموافقة نفسها. فإذا طلب التطبيق صلاحيات أكثر مما يراه المستخدم مناسباً، لم يكن أمامه سوى منح الطلب كاملاً أو رفضه.
وتوضح Cloudflare أن خوادم MCP تمثل حالة استخدام واضحة لهذه المشكلة؛ فقد يطلب خادم MCP مجموعة واسعة من الصلاحيات لأن الوكيل قد يحتاج نظرياً إلى جميعها، في حين لا يرغب المستخدم بالضرورة في منح الوكيل هذا المستوى من الوصول. وقبل إطلاق الميزة، كان على المطور بناء شاشة مخصصة لاختيار النطاقات قبل تحويل المستخدم إلى تدفق موافقة Cloudflare.
كيف تعمل النطاقات الاختيارية؟
- يمكن للمطور تحديد نطاقات معينة على أنها إلزامية أو اختيارية عند إعداد عميل OAuth.
- يستطيع المستخدم إلغاء تحديد النطاقات الاختيارية ضمن مجموعة الصلاحيات المطلوبة في عملية التفويض الحالية.
- تظل التجربة الافتراضية كما هي إذا لم يفعّل العميل النطاقات الاختيارية، كما تمنح شاشة الموافقة المجموعة المطلوبة كاملة عند عدم إلغاء أي نطاق اختياري.
النقطة المهمة هي أن التقييم يتم وفق النطاقات التي طلبها التطبيق في تدفق تفويض محدد، وليس وفق جميع النطاقات المعدة على العميل. فلو كان العميل يتضمن user-details.read وworkers-scripts.write وworkers-kv-storage.write وzone.read، مع جعل النطاقين الأخيرين اختياريين، فإن طلب النطاقات الأربعة يترك للمستخدم حرية إلغاء الأخيرين فقط.
أما إذا طلب العميل لاحقاً workers-scripts.write وzone.read فقط، فسيُقيّم هذان النطاقان وحدهما في تلك العملية. ولن تظهر النطاقات الأخرى أو تُفرض، لأنها لم تكن جزءاً من الطلب الحالي. ويساعد ذلك على إبقاء شاشة الموافقة مركزة على المهمة المطلوبة بدلاً من عرض كل القدرات التي يمكن للتطبيق طلبها مستقبلاً.
ما الذي يتغير عملياً للمطورين؟
عند إلغاء المستخدم لبعض النطاقات الاختيارية وإكمال التفويض، سيحتوي رمز الوصول الناتج على الصلاحيات التي وافق عليها فقط. لذلك يجب على المطور فحص مجموعة النطاقات الممنوحة بعد استبدال رمز التفويض، بدلاً من افتراض أن التطبيق حصل على كامل المجموعة المطلوبة.
يعني ذلك أن التطبيقات، وخصوصاً الوكلاء البرمجيين، تحتاج إلى التعامل بسلاسة مع منح جزئي للصلاحيات. كما أن طلب الحد الأدنى اللازم من الوصول، وجعل الصلاحيات الإضافية اختيارية، يوضح للمستخدم أن التطبيق يحترم قراره بشأن حدود الوصول.
التوسع إلى منتجات Cloudflare
قالت Cloudflare إنها ستوسع خلال الأسابيع التالية نطاقات الأدوار على مستوى الحساب والمنطقة لتغطي تقريباً جميع منتجاتها، بما يشمل مزيداً من أدوار رموز API وخيارات عضوية الحساب ونطاقات OAuth. ويمكن للمطورين البدء عبر وثائق Third Party OAuth أو من صفحة تطبيقات OAuth في لوحة التحكم.
وذكرت الشركة أن الميزة طُورت بمساعدة 1,111 متدرباً، مشيدة بمساهمات Miller Vargas وJosé Enrique Rodriguez. ووفق المادة، يدرس Vargas علوم الحاسوب والرياضيات في University of Texas - Austin، بينما يدرس Rodriguez الهندسة وذكاء البيانات والأمن السيبراني في Universidad Panamericana.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.