المصادقة

تحتاج معظم واجهات API إلى بيانات اعتماد في كل استدعاء. يتيح لك Getman ضبطها مرة واحدة على مستوى المشروع أو المجموعة أو المجلد، فيرثها كل طلب إلا إذا حدد غير ذلك. تبقى القيم السرية في سلسلة المفاتيح، ولا تصل أبدا إلى ملف في Git.

كيف ترث المصادقة

مصادقة الطلب هي أول قيمة ليست Inherit، وتُفحص بهذا الترتيب:

1. الطلب نفسه
2. مجلداته، من الأعمق إلى الأعلى
3. المجموعة
4. المشروع

اضبط Access على مستوى المشروع للحالة المعتادة، مثل رمز bearer يستخدمه كل طلب. تجاوزه في مجلد أو طلب فقط عندما تحتاج نقطة نهاية واحدة إلى شيء مختلف، مثل مسار تسجيل دخول عام مع No auth.

لضبط مصادقة المشروع، افتح Project settings واختر Access.

أنواع المصادقة

يقدم لسان Auth هذه الأنواع:

النوع	ما الذي يرسله
Inherit	ما يضبطه المستوى الأعلى
No auth	لا شيء. استخدمه لإيقاف المصادقة لطلب واحد
Bearer token	Authorization: Bearer <token>. يمكنك تغيير البادئة
API key	مفتاح في ترويسة أو في معاملات الاستعلام، تحت الاسم الذي تختاره
Basic	Authorization: Basic مع اسم مستخدم وكلمة مرور
OAuth 2.0	رمز من خادم تفويض، موصوف أدناه
Custom headers	ترويسات تعرّفها، لواجهات لها مخطط خاص
Cookies	ملفات تعريف ارتباط تضبطها يدويا

ضع القيم السرية في متغير سري، مثل {{token}}، بدلا من كتابتها في الحقل. عندها تبقى القيمة خارج عمليات التصدير والعقد.

OAuth 2.0

اختر OAuth 2.0، ثم اختر Grant type:

Grant type	استخدمه عندما
Client credentials	يستدعي خادم أو سكربت الواجهة بهويته الخاصة
Password	تسجل الدخول كمستخدم باسم مستخدم وكلمة مرور
Authorization code	يسجل المستخدم الدخول عبر المتصفح. يستخدم Getman PKCE
Refresh token	لديك refresh token بالفعل وتريد access token جديدا

املأ Token URL وClient ID وClient secret وScope وAudience حيثما يحتاجها المزود. في حالة Authorization code، اضبط أيضا Authorize URL وRedirect URI. يجب أن يطابق redirect URI الذي سجّلته لدى المزود.

يقترح حقل Client secret حفظ القيمة في متغير سري. في حالة Client credentials، يختار الإعداد Send client credentials بين إرسالها في الجسم أو في ترويسة Basic.

لا يُصدَّر OAuth 2.0 إلى مقاطع الشيفرة.

تسجيل الدخول تلقائيا بتدفق الرموز

تصدر كثير من الواجهات رمزا قصير العمر من طلب تسجيل دخول. يستطيع Getman تشغيل تسجيل الدخول نيابة عنك، وإعادة المحاولة عند فشل الطلب:

1. افتح Project settings ← Access.
2. فعّل Use token flow.
3. اختر Login request. يُشغَّل لإحضار رمز، وتُخزَّن قيم استجابته في متغيرات.
4. اضبط Extract from على مسار الجسم accessToken، وStore in variable على token.
5. اضبط Refresh on status على الرموز التي يجب أن تُطلق تسجيل دخول جديدا، مثل 401, 403.

عندما يتلقى طلب إحدى هذه الحالات، يعيد Getman تسجيل الدخول ويعيد المحاولة مرة واحدة. تستمر طلباتك في استخدام {{token}} كالمعتاد.

استخدم Refresh request عندما يجدد طلب منفصل الرمز بدلا من تسجيل دخول كامل.

المتغيرات والأسرار

تُحل المتغيرات بهذا الترتيب، ويفوز أول تطابق:

1. قيم التشغيل التي يضبطها مستخرج أو سكربت أثناء التشغيل
2. البيئة التي اخترتها
3. المجموعة
4. المشروع
5. المتغيرات العامة

تُخفى المتغيرات السرية في الواجهة، وتُزال قيمها من المخرجات. يحفظ Getman القيم السرية في سلسلة مفاتيح نظامك، تحت الخدمة dev.getman.app والمستخدم master-key لمفتاح التشفير. إذا لم تكن سلسلة المفاتيح متاحة، يلجأ Getman إلى ملف master.key.

لملء الأسرار في التطبيق، افتح Environments واختر البيئة، ثم اكتب كل قيمة. لا تُكتب القيم أبدا في ملفات environments/*.yaml داخل مساحة عمل الفريق، فهي تحتفظ بأسماء المتغيرات مع قيم فارغة.

الأسرار لسطر الأوامر والوكلاء

يأخذ سطر الأوامر والوكلاء البرمجيون قيم الأسرار من متغيرات بيئة باسم GETMAN_VAR_<KEY>، حيث <KEY> هو اسم المتغير:

export GETMAN_VAR_password="your-demo-password"
getman run "Shop API" --workspace getman --env Local

اضبط المتغيرات في الصدفة التي تشغّل الوكيل أو مهمة CI. يزيل Getman القيم من مخرجاته.

التحقق من المصادقة

1. أرسل طلبا يحتاج إلى مصادقة. تعني الحالة 401 أن بيانات الاعتماد مفقودة أو خاطئة.
2. افتح لسان Tests في الاستجابة، وأضف تأكيد حالة إذا كنت تتوقع 401 في حالة سلبية. راجع الاختبار.
3. في تدفق الرموز، أرسل طلبا بعد انتهاء صلاحية الرمز، وتحقق من أن Getman يسجل الدخول من جديد.

إذا استمر فشل الطلب، تسرد استكشاف الأخطاء الأسباب الشائعة.