إدارة الرموز

تُعد هذه الميزة جزءًا من خطط الفريق والمؤسسات.

يتيح لك إدارة الرموز (Tokens Management) لمديري المؤسسات الإشراف على رموز الوصول (Access Tokens) داخل مؤسستهم، مما يضمن وصولاً آمناً إلى موارد المؤسسة.

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

عرض رموز الوصول وإدارتها

يعرضت ميزة قائمة الرموز جميع رموز الوصول داخل مؤسستك. يمكن للمشرفين:

• مراقبة استخدام الرموز وتحديد المخاطر الأمنية المحتملة أو منعها:
  • الوصول غير المصرّح به إلى الموارد الخاصة (تسريبات)
  • نطاقات وصول واسعة بشكل مفرط
  • نظافة رموز غير مثلى (مثل الرموز التي لم يتم تدويرها منذ فترة طويلة)
• تحديد الرموز غير النشطة أو غير المستخدمة

تعرض الرموز الدقيقة صلاحياتها المحددة:

تُخفى الرموز المسحوبة من القائمة افتراضيًا. استخدم مفتاح إظهار الرموز المسحوبة الموجود أعلى القائمة لتضمينها في العرض.

يظهر شارة حالة REVOKED لأي رمز تم إلغاؤه بغض النظر عن سياسة الرموز الخاصة بالمنظمة. ولا تظهر شارات PENDING وAPPROVED وDENIED إلا في المنظمات التي تم فيها تفعيل سياسة “يتطلب موافقة المسؤول”، لأن هذه الحالات لا تُنشأ إلا عبر سير عمل الموافقة.

سياسة الرموز

يمكن لمسؤولي تنظيمات فريق & المؤسسة فرض السياسات التالية:

مراجعة تفويض الرموز

عند ضبط سياسة الرموز على “يتطلب موافقة المسؤول”، يمكن لمسؤولي المنظمة مراجعة تفاصيل جميع الرموز الدقيقة التي تصل إلى الموارد المملوكة للمنظمة، والموافقة على الوصول أو رفضه. عندما يدخل رمز جديد في حالة قيد الانتظار، يتلقى ما يصل إلى 50 من مسؤولي المنظمة الذين تم تأكيد عناوين بريدهم الإلكتروني إشعارًا يحتوي على رابط مباشر إلى صفحة مراجعة الرمز. لا يُرسل أي إشعار عندما يتم الموافقة على الرمز تلقائيًا (مثلًا، لأن المنشئ هو مسؤول في المنظمة).

• رموز قيد الانتظار في انتظار قرار من المسؤول
• تمت الموافقة على الرموز المعتمدة وهي نشطة
• تم حظر الوصول إلى موارد المنظمة لرموز Denied

عندما يُعتمد رمز أو يُرفض، يتلقى مالك الرمز إشعارًا عبر البريد الإلكتروني.

إن الرفض ليس دائمًا: يمكن لمدير النظام لاحقًا الموافقة على رمز مرفوض، مما يُعيد وصوله. وبالمثل، يمكن رفض رمز تمت الموافقة عليه مسبقًا في أي وقت، مما يُزيل وصوله القائم على الموافقة فورًا.

لا تكون أسماء الرموز (Tokens) مرئية للمشرفين إلا عند تفعيل سياسة «يتطلب موافقة المشرف».

ما يراه الأعضاء عند الحظر

تتلقى الأعضاء الذين تكون رموزهم معلقة أو مرفوضة خطأ 403 عند الوصول إلى موارد المنظمة: “بسبب سياسة رموز المنظمة، يجب أن يتم اعتماد رمزك من قبل المنظمة قبل أن تتمكن من الوصول إلى هذا المورد.”

رسالة الخطأ متطابقة لكلتا الحالتين: المعلقة والمرفوضة. للاطلاع على الحالة، يمكن للأعضاء الانتقال إلى صفحة تحرير الرمز الفردي. تعرض صفحة إعدادات إدارة الرموز الخاصة بمسؤول المنظمة شارات الحالة لجميع رموز الأعضاء.

الرفض مقابل الإلغاء

لدى المشرفين طريقتان لإزالة صلاحية رمز الوصول إلى منظمة:

استخدم deny عند إدارة الوصول ضمن سير عمل الموافقة (ينتقل الرمز إلى حالة denied ويمكن إعادة الموافقة عليه لاحقًا). استخدم revoke عندما تحتاج إلى قطع وصول الرمز إلى المنظمة بشكل دائم.

عرض الرموز عبر واجهة برمجة التطبيقات

قائمة الرموز المعروضة في واجهة الإعدادات متاحة أيضاً برمجياً:

# ORG_NAME should be your organization name and ADMIN_HF_TOKEN an admin's access token
curl -H "Authorization: Bearer ${ADMIN_HF_TOKEN}" \
  "https://huggingface.co/api/organizations/${ORG_NAME}/settings/tokens"

الاستجابة عبارة عن مصفوفة من رموز الوصول للأعضاء. راجع مرجع OpenAPI للحصول على المخطط الكامل: GET /api/organizations/<name>/settings/tokens

بشكل افتراضي، يتم إخفاء الرموز المسحوبة؛ مرّر q=status:all لتشملها، كما في مفتاح إظهار الرموز المسحوبة في واجهة المستخدم.

إلغاء رموز

تُعد هذه الميزة جزءًا من خطة Enterprise وما فوقها.

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

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

تتلقى الأعضاء الذين تم إلغاء صلاحية رموزهم خطأ 403 مع الرسالة التالية: “تم إلغاء رمزك من قِبل مسؤول المنظمة، ولم يعد بإمكانك الوصول إلى موارد المنظمة. يرجى التواصل معهم لمزيد من المعلومات.” وتظهر هذه الرسالة بغض النظر عما إذا كانت المنظمة تستخدم سياسة “يتطلب موافقة المسؤول”.

السحب عبر واجهة برمجة التطبيقات

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

# ORG_NAME should be your organization name and ADMIN_HF_TOKEN an admin's access token
# TOKEN_ID is the 24-character id shown on the org token settings page (or returned by the tokens listing API)
curl -X POST "https://huggingface.co/api/organizations/${ORG_NAME}/settings/tokens/${TOKEN_ID}/revoke" \
  -H "Authorization: Bearer ${ADMIN_HF_TOKEN}"

لا يمكن للمسؤول إلغاء توكنه الخاص: يُرفض الطلب الذي يطابق معرّف توكنه التوكن المستخدم للمصادقة مع خطأ 403.

تُلغي هذه النقطة النهائية وصول الرمز إلى مؤسستك فقط؛ ويستمر الرمز في العمل على موارد أخرى لمالكه. لتعطيل رمز مسرّب في كل مكان، استخدم POST /api/credentials/revoke بدلاً من ذلك، حيث لا يتطلب المصادقة ويقبل دفعة من قيم الرموز الخام.

إصدار الرموز برمجياً

تُعد هذه الميزة جزءًا من خطة Enterprise وما فوقها.

للمنظمات التي تحتاج إلى إصدار رموز وصول لبرمجة لأعضائها (مثلًا، للمنصات الداخلية، أو خطوط CI/CD، أو التكاملات المخصصة)، راجع OAuth Token Exchange. تتيح لك هذه الميزة في خطة Enterprise إصدار رموز محددة النطاق لأعضاء المنظمة من خدماتك الخلفية دون الحاجة إلى موافقة تفاعلية من المستخدم.

حسابات الخدمة

تُعد هذه الميزة جزءًا من خطة Enterprise وما فوقها.

للوصول الآلي الذي تملكه المنظمة بدلاً من عضو فردي، يمكن للمشرفين إنشاء حسابات الخدمة وإصدار رموز وصول دقيقة النطاق مخصصة لموارد منظمته.