API Hop

الوثائق

وثائق API Hop

الأمان والإعداد

إنشاء مفاتيح API والتحكم في صلاحياتها وتدويرها وممارسات الأمان.

المبادئ الأساسية لحماية مفاتيح API هي عدم كشفها واستخدام أقل صلاحيات لازمة وتدويرها بانتظام وإبقاء الاستخدام قابلا للتتبع.

كيف أدير مفاتيح API وأحميها؟

الممارسات المقترحة:

  • لا تضع مفاتيح API في مستودعات عامة أو صفحات الواجهة الأمامية أو حزم تطبيقات الهاتف أو لقطات الشاشة.
  • اقرأ مفاتيح API من متغيرات البيئة أو مدير أسرار على الخادم.
  • أنشئ مفاتيح API مستقلة للتطوير والاختبار والإنتاج.
  • أنشئ مفاتيح مستقلة للخدمات أو التطبيقات المختلفة لتحسين التتبع والعزل.
  • اضبط صلاحيات النماذج حسب الحاجة وحدد تواريخ انتهاء حيث يلزم.
  • دور مفاتيح API بانتظام؛ ودورها فورا بعد تغييرات الموظفين أو إيقاف الخدمة أو الاشتباه في تسرب.

إذا كان من المحتمل تسرب مفتاح API:

  1. عطل المفتاح القديم أو احذفه أو دوره فورا.
  2. أنشئ مفتاحا جديدا وحدث جميع الخدمات المعتمدة عليه.
  3. راجع الاستخدام الأخير وتغيرات الرصيد والإنفاق غير المعتاد.
  4. ضيق صلاحيات النماذج وفكر في مدة صلاحية أقصر.
  5. راجع مسار التسرب، مثل المستودعات أو السجلات أو إعداد CI أو عملاء الأطراف الثالثة.

قد يؤدي تسرب مفتاح API إلى استدعاءات غير مصرح بها وخسائر مالية. ينبغي حماية مفاتيح الاختبار أيضا مثل أسرار الإنتاج.

هل يمكنني عرض مفتاح API كاملا مرة أخرى بعد إنشائه؟

لا. يعرض مفتاح API كاملا أثناء تدفق الإنشاء الناجح فقط. وتعرض وحدة التحكم بعد ذلك معاينة مقنعة فقط.

قبل إغلاق مربع حوار الإنشاء، خزن المفتاح في متغير بيئة على الخادم أو مدير أسرار. لا يمكن استعادة مفتاح مفقود عبر واجهات API للمستخدم أو المسؤول. أنشئ بديلا وحدث الجهة المستدعية ثم احذف المفتاح القديم. يستخدم قالب تكامل الذكاء الاصطناعي في الوثائق العنصر النائب <API_KEY> ولا يحمل المفاتيح السابقة.

كيف أرسل مفتاح API؟

أرسل مفاتيح API في ترويسات الطلب فقط. نوصي بما يلي:

http
Authorization: Bearer YOUR_API_KEY

يمكنك أيضا استخدام:

http
X-API-Key: YOUR_API_KEY

لا تضع أبدا بيانات اعتماد API Hop API في استعلام URL. تؤدي الأسماء المشابهة لبيانات الاعتماد (apiKey وapi_key وapikey وx-api-key وkey) عادة إلى HTTP 400. تطبق استثناءات ضيقة لمعاملات أعمال Similarweb على طلبات GET فقط: يقبل /v1/similarweb/websites/backlinks اسم مضيف واحدا في Key بحرف أول كبير؛ وتقبل /v1/similarweb/websites/outgoing-traffic و/websites/incoming-referrals و/websites/similar-sites/suggestions اسم مضيف واحدا في key بحروف صغيرة (كلها تحت /v1/similarweb). تحدد هذه الحقول موقعا مستهدفا، وليست بيانات اعتماد API. يجب أن تكون أسماء المضيفين صحيحة. تظل التكرارات وحالة الأحرف الخاطئة والقيم المشابهة لبيانات الاعتماد وحقول اعتماد الاستعلام الإضافية محظورة. صادق دائما عبر ترويسة طلب، بما في ذلك مسارات Similarweb. راجع مثال طلب Similarweb.

لا تؤثر هذه القاعدة في معاملات الأعمال الأخرى مثل OAuth token أو apiKeyId أو username أو pagination_token.