أعلنت Cloudflare إطلاق Cloudflare Access for Workers، وهي مجموعة أدوات تتيح ربط سياسة Access مباشرة بتطبيق Worker أو بجميع تطبيقات Workers ضمن الحساب. وبموجب هذا الربط، تصبح التطبيقات خلف تسجيل دخول الشركة افتراضياً، من دون الاعتماد على تذكّر كل مطور إعداد ضوابط الوصول بشكل منفصل.
تأتي الخطوة في ظل قدرة الموظفين، بدعم من أدوات الذكاء الاصطناعي، على بناء التطبيقات ونشرها بسرعة أكبر. وترى Cloudflare أن هذه السرعة قد تؤدي أيضاً إلى نشر تطبيقات داخلية أو بيانات خاصة على الإنترنت العام عن طريق الخطأ، لذلك صممت الأدوات الجديدة لتجعل حماية التطبيقات المستضافة على Workers جزءاً من عملية النشر نفسها.
حماية التطبيق بغض النظر عن طريقة الوصول
عند تفعيل Access على Worker، تفرض Cloudflare المصادقة قبل وصول أي طلب إلى كود التطبيق. وينطبق ذلك سواء وصل المستخدم إلى التطبيق عبر نطاق مخصص، أو مسار، أو نطاق فرعي على workers.dev، أو عنوان معاينة.
في السابق، كان إعداد Access يتم على مستوى اسم المضيف، ما يعني إنشاء سياسات منفصلة لكل نطاق يمكن أن يصل من خلاله المستخدم إلى Worker. وكان إضافة نطاق مخصص جديد تتطلب تحديث السياسة أولاً، وإلا أصبح ذلك النطاق قابلاً للوصول من دون مصادقة. أما الآن، فتُربط السياسة بالـ Worker نفسه، ما يؤدي إلى حماية النطاقات وعناوين URL المرتبطة به تلقائياً.
يمكن اختيار نطاق الحماية وفقاً للحاجة:
- حماية عناوين المعاينة فقط، بما في ذلك عناوين workers.dev أو النطاقات المخصصة المستخدمة للمعاينات.
- حماية جميع أسماء المضيفين المرتبطة بالتطبيق، وتشمل النطاقات المخصصة والمسارات ونطاقات workers.dev وعناوين المعاينة.
سياسة افتراضية على مستوى الحساب
يمكن للفرق التي تدير عدداً كبيراً من تطبيقات Workers ضبط سياسة Access مرة واحدة على مستوى الحساب. عندها تصبح كل التطبيقات الحالية والمستقبلية خاصة منذ لحظة إنشائها، مع إمكانية تحديد ما إذا كانت السياسة ستغطي حركة عناوين المعاينة، أو حركة الإنتاج، أو كليهما.
قد يكون خيار المعاينات فقط مناسباً للتطبيقات التي يُراد إبقاؤها عامة في بيئة الإنتاج، مع منع كشف الإصدارات قيد التطوير. كما تتيح Cloudflare تجاوز سياسة الحساب لتطبيق Worker محدد إذا كان من المفترض أن يكون عاماً.
أما من لا يحتاج إلى سياسة شاملة، فيستطيع تطبيق Access على Worker واحد مباشرة. وتعرض علامة التبويب الجديدة الخاصة بـ Access داخل واجهة Worker السياسات السارية على التطبيق. وعند وجود أكثر من سياسة، تكون الأولوية للسياسة الأكثر تحديداً، بالترتيب التالي: سياسات اسم المضيف، ثم سياسات Worker، ثم سياسات الحساب.
هوية المستخدم داخل كود التطبيق
تتيح Access أيضاً معرفة هوية المستخدم الذي يرسل كل طلب إلى التطبيق، بما في ذلك بريده الإلكتروني واسمه ومجموعاته. وتقول Cloudflare إن هذه البيانات يمكن استخدامها لتخصيص المحتوى، أو فرض الصلاحيات، أو تسجيل النشاط لكل مستخدم.
تظهر معلومات الهوية داخل كائن السياق ctx الخاص بـ Worker، وتحديداً من خلال ctx.access. ويمكن للتطبيق استدعاء ctx.access.getIdentity() للحصول على هوية المستخدم المصادق عليه، من دون الحاجة إلى تنفيذ التحقق من JSON Web Token يدوياً، مثل تحليل الرمز والتحقق من توقيعه واستخراج مطالباته.
تدعم Access ربط موفر الهوية الحالي لدى المؤسسة، كما يمكن تقييد الوصول وفق عناوين بريد إلكتروني محددة أو نطاقات بريدية أو مجموعات. وبالنسبة إلى الوكلاء، يمكن منح الوصول عبر رموز الخدمة.
اختبار محلي ومنصات داخلية
يمكن اختبار سلوك الهوية محلياً باستخدام wrangler dev عبر إضافة إعداد Access إلى ملف wrangler.jsonc لمحاكاة مستخدم مصادق عليه. وبذلك يستطيع المطور تبديل البريد الإلكتروني في الإعداد والتحقق من عرض المحتوى المناسب لكل مستخدم قبل النشر.
كما طرحت Cloudflare مثالاً مفتوح المصدر لمنصة داخلية تتيح نشر مواقع ثابتة بأسلوب السحب والإفلات، مع جعل كل Worker منشور خاصاً افتراضياً. وتستفيد هذه البنية من Workers for Platforms، حيث تمر حركة التطبيقات الموجودة داخل مساحة الأسماء عبر Worker موزع واحد. وعند وضع سياسة Access على ذلك الـ Worker، تصبح التطبيقات المنشورة من خلاله خاصة افتراضياً.
التوفر والبنية التقنية
أصبحت الميزة متاحة للجميع عبر لوحة التحكم، مع توفير وثائق Cloudflare Access for Workers للبدء. وتستند الإمكانية الجديدة إلى FL2، وهو وكيل وسيط معياري مبني باستخدام Rust ويشغّل بنية Cloudflare الطرفية.
ولتمكين تطبيق Access على مستوى Worker بدلاً من اسم المضيف، فصلت Cloudflare توجيه Workers عن تنفيذها ونقلت منطق التوجيه إلى مرحلة تسبق Access. وتوضح الشركة أن نظام FL2 ذي الوحدات المحددة والمراحل المرتبة ساعدها على إدارة هذا التغيير، إذ يعلن كل جزء مدخلاته ومخرجاته بشكل ثابت، ما أتاح استخدام المترجم لاكتشاف التفاعلات غير السليمة بين المراحل أثناء إعادة الهيكلة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.