صلاحيات Vercel Connect: من يملك بيانات الاعتماد المشتركة؟

تتيح صلاحيات Vercel Connect الآن إسناد بيانات اعتماد الموصّل المشتركة إلى مسؤول محدد، من دون منحه دور Owner في فريق Vercel. ففي 11 سبتمبر 2026، أضافت Vercel ميزة Connector Permissions إلى فرق Pro وEnterprise، ليتمكن Owner من قصر إنشاء الموصّلات وإدارتها على أصحاب دور Owner ومن لديهم صلاحية Connector Manager.

لكن ثمة تفصيل مهم: دور Member يتضمن أصلًا صلاحية Connector Manager. لذلك لا يرسم هذا الإعداد حدًا ضيقًا للملكية إلا إذا كانت الأدوار المسندة داخل الفريق منضبطة بالقدر نفسه.

ما الذي تغيّره صلاحيات Vercel Connect فعليًا؟

الموصّل في Vercel Connect هو سجل يملكه الفريق ويمثّل خدمة مثل Slack أو GitHub أو Microsoft أو مزوّدًا مخصصًا. ويمكنه الاحتفاظ ببيانات الاعتماد التي تستخدمها عدة مشاريع أو التوسط في الوصول إليها، لذا فإن تغييره عملية تخص الفريق كله، لا تعديلًا عاديًا داخل تطبيق.

تضيف Connector Permissions طبقة تحكم بشرية إلى إدارة هذا السجل. يفعّل Owner التقييد من Team Settings؛ وبعد ذلك، لا يستطيع إنشاء الموصّلات أو إدارتها إلا Owner أو شخص مُنح الصلاحية الموسعة Connector Manager.

تشمل هذه الصلاحية الموصّلات على مستوى الفريق، واتصالات المشاريع، وعمليات التثبيت، والرموز. لكنها لا تختزل جميع قرارات الوصول في مفتاح واحد.

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

يشرح الدليل السابق لمصادقة Vercel Connect مسار تبادل الرموز بمزيد من التفصيل. أما هذا الإصدار فيغيّر من يستطيع صيانة الاتصال، لا الطريقة التي يثبت بها التطبيق العامل حقه في طلب رمز.

المعادلة التجارية تبدأ بحجم مجموعة التغيير

الرقم المفيد هنا ليس حدًا آخر لواجهة API، بل عدد الأشخاص القادرين على تغيير مورد على مستوى الفريق يحمل بيانات اعتماد.

عندما يستطيع كل مطوّر تعديل موصّل مشترك، تتسع مساحة المراجعة مع كل تغيير في التوظيف أو تسليم لمتعاقد أو إصلاح عاجل في بيئة الإنتاج. تتيح Connector Permissions تحديد مجموعة الإدارة صراحة، بينما يواصل بقية الفريق البناء اعتمادًا على روابط مشاريع سبق أن وافق عليها المسؤول.

لم يعلن إصدار 11 سبتمبر عن تغيير مباشر في السعر. تحتسب Vercel رسوم Connect بناءً على طلبات الرموز والمشغّلات، لا على عدد الأشخاص الممنوحين صلاحية Connector Manager. وتشير صفحة منفصلة لأسعار Connect إلى أن أسعار النسخة التجريبية المحدّثة تدخل حيز التنفيذ في 25 سبتمبر 2026: تبلغ كلفة Pro مقدار $3.00 لكل 1,000 طلب رمز، بينما تُحدد أسعار Enterprise بصورة مخصصة. ولا يوصف إعداد الصلاحيات بأنه يغيّر عداد الاستخدام وقت التشغيل.

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

تسليم منظم داخل فريق واحد

لنأخذ Northstar Agency مثالًا بأسماء واضحة. تتولى Maya دور Vercel Owner. ويحمل Jon دور Developer مع صلاحية Connector Manager، وهو المسؤول عن صيانة اتصالات الخدمات المشتركة. أما Priya فتحمل دور Developer من دون Connector Manager وتتولى بناء تطبيق العميل، بينما تدير Leah قاعدة العمل التي تقرر ما إذا كان يجوز للتطبيق إرسال أي شيء أو تحديثه.

فيما يلي مسار التسليم الذي يبقي هذه المهام منفصلة.

1. 1

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

   تراجع Maya قائمة الفريق قبل تفعيل التقييد. كل من يحمل دور Owner أو Member لديه أصلًا Connector Manager. ويمكن منح Connector Manager كصلاحية موسعة لمن يحمل دور Developer أو Security أو Billing أو Viewer أو Contributor، عندما يلائم ذلك الدور الأساسي بقية مهام الشخص.

2. 2

   عيّن مسؤول صيانة الموصّل

   تفتح Maya قسم Settings في الفريق، ثم تنتقل إلى Members وتستخدم Manage Role لحساب Jon. يحتفظ Jon بدور Developer ويحصل على Connector Manager. ويوثق سجل التسليم اسم الموصّل وحساب المزوّد والمشاريع والبيئات المرتبطة والمسؤول لدى المزوّد ومسار التصعيد لتدوير بيانات الاعتماد أو إلغائها.

3. 3

   فعّل Connector Permissions

   تفتح Maya قسم Team Settings، وتعثر على Connector Permissions، ثم تفعّل التقييد. يستطيع Jon عندئذ إنشاء الموصّلات وإدارتها من دون الحصول على دور Owner الكامل.

1. 1

   أبقِ نطاق المزوّد مستقلًا

   يسجل Jon النطاقات أو الموارد أو تفاصيل التفويض المطلوبة من المزوّد. تجيب صلاحية Connector Manager عن سؤال من يحق له صيانة كائن Vercel، بينما تحدد موافقة المزوّد ما الذي تستطيع بيانات الاعتماد الناتجة فعله. وتظل قاعدة الموافقة التي تديرها Leah داخل التطبيق، لأن أيًا من الإعدادين لا يقرر ما إذا كان ينبغي تنفيذ إجراء تجاري حقيقي.

2. 2

   اختبر مسار الطلب

   تشغّل Priya طلبًا محدودًا واحدًا من مشروع QA المرتبط. ويكون المسار المحدد بالترتيب: هوية OIDC لنشر QA، ثم رابط مشروع Vercel Connect، ثم رمز مزوّد بنطاق قراءة، ثم استجابة واجهة API لدى المزوّد. يؤكد Jon طلب الرمز والتفويض في تبويب Observability الخاص بالموصّل، وتتأكد Maya أيضًا من أن Priya لا تستطيع استخدام مسار إدارة الموصّل.

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

من ينبغي له استخدام هذا الإعداد الآن؟

شركة ناشئة على Pro ولديها مهندس منصات واحد

يمكن للمؤسس الاحتفاظ بدور Owner ومنح مهندس المنصات Connector Manager. يواصل مهندسو المنتج العمل عبر المشاريع المرتبطة، بينما يصبح لتغييرات الموصّل مسؤول صيانة واحد ومسار تصعيد واحد. المحصلة هي تقليل انتظار المؤسس من دون توسيع ملكية الفريق الكاملة.

فريق أمن على Enterprise

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

وكالة تطلق عدة تطبيقات للعملاء

يستطيع مشغّل الوكالة تعيين مسؤول للموصّل في كل بيئة عميل، مع إبقاء متعاقدي التسليم ضمن المشاريع المسندة إليهم. وتظهر الفائدة عند التطبيق التالي: يعيد الفريق استخدام مسار اتصال معتمد، من دون منح كل مطوّر صلاحية تعديل طبقة بيانات الاعتماد المشتركة.

فريق عمليات يضيف إجراءات للوكلاء

ينبغي لقائد العمليات استخدام Connector Permissions لتسليم مسؤولية بيانات الاعتماد، ثم إبقاء الإجراءات عالية الأثر خلف خطوة الموافقة الخاصة بالمنتج. هكذا تصبح المسؤوليات واضحة: يستطيع Jon إصلاح الاتصال، وتستطيع Priya إطلاق سير العمل، وتقرر Leah متى يجوز تغيير سجل عميل أو رسالة خارجية.

ما الذي لا يقدمه هذا الإعداد؟

تفعيل Connector Permissions ليس دليلًا على إلغاء صلاحية وصول المزوّد الحالية. فالإلغاء إجراء مستقل، وتشير Vercel إلى أن التعطيل الفوري يعتمد على إتاحة المزوّد نقطة نهاية للإلغاء.

كذلك لا يضيّق الإعداد نطاقات المزوّد، ولا يغيّر بيئات النشر المرتبطة التي تستطيع طلب الرموز، ولا يضيف موافقة بشرية إلى إجراءات الوكلاء، ولا يخفض رسوم استخدام Connect. لكل من هذه الضوابط جهة مسؤولة مستقلة.

لا تتأثر فرق Hobby، لأن تقييد الإدارة هذا مخصص لفئتي Pro وEnterprise. وقد لا يحتاج نموذج أولي فردي بلا موصّل مشترك إلى عملية تسليم بعد. أما الفريق الذي يستخدم بيانات اعتماد مشتركة في الإنتاج أو تطبيقات عدة بُنيت باستخدام الوكلاء أو مساهمين من خارج المؤسسة، فعليه وضع هذا الحد قبل إضافة الموصّل التالي.

ما الذي ينبغي إنجازه يوم الاثنين؟

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

أغلق المهمة بسطر مكتوب وطلب حقيقي واحد: Maya مسؤولة عن السياسة، وJon مسؤول عن صيانة الموصّل، وقد اختُبر مسار القراءة في QA بدءًا من هوية النشر، مرورًا برابط المشروع، ووصولًا إلى استجابة المزوّد. هذا هو التسليم؛ أما المفتاح فليس سوى أداة تطبيقه.

اشترك في النشرة لتصلك التغييرات التالية على المنصات بلغة واضحة.