Skip to main content
تتيح تطبيقات OAuth لتطبيقات الجهات الخارجية الوصول إلى Teable نيابةً عن المستخدمين. يوضح هذا الدليل كيفية إنشاء تطبيق OAuth وتهيئته، وتنفيذ مسار التفويض في OAuth 2.0، واستخدام رموز الوصول للتفاعل مع Teable API. يدعم Teable ثلاثة أوضاع للتفويض في OAuth 2.0:
  • رمز التفويض + سر العميل: لتطبيقات الويب التي لديها خادم خلفي
  • رمز التفويض + PKCE: للتطبيقات الأصلية وأدوات CLI وتطبيقات الصفحة الواحدة وغيرها من العملاء العامّين الذين لا يمكنهم تخزين سر العميل بأمان
  • منح التفويض للجهاز: للعملاء الذين لا يمكنهم تلقي إعادة توجيه من المتصفح مطلقًا، مثل أداة CLI تعمل عبر SSH أو داخل حاوية أو في بيئة تطوير سحابية

إنشاء تطبيق OAuth

  1. انتقل إلى الإعدادات > تطبيقات OAuth في حسابك على Teable.
  2. انقر على تطبيقات OAuth جديدة لإنشاء تطبيق جديد.
  3. أدخل المعلومات المطلوبة:
    • اسم تطبيق OAuth: اسم وصفي لتطبيقك
    • عنوان URL للصفحة الرئيسية: عنوان URL الكامل لموقع تطبيقك
    • عنوان URL لمعاودة الاتصال: عنوان URL الذي سيُعاد توجيه المستخدمين إليه بعد التفويض
    • النطاقات: الأذونات التي يحتاج إليها تطبيقك
    • تمكين مسار الجهاز: يكون معطّلًا افتراضيًا. لا تمكّنه إلا إذا كان تطبيقك يسجّل دخول المستخدمين باستخدام رمز جهاز
  4. بعد إنشاء التطبيق، أنشئ سر العميل. تأكد من نسخه وحفظه بأمان، إذ لن تتمكن من رؤيته مرة أخرى.
ستتلقى معرّف العميل، وستحتاج إلى إنشاء سر العميل. حافظ على أمان بيانات الاعتماد هذه ولا تكشفها مطلقًا في الشيفرة من جانب العميل. عند استخدام مسار PKCE، لا يلزم سر عميل.

النطاقات المتاحة

تحدد النطاقات الإجراءات التي يمكن لتطبيق OAuth تنفيذها. تُنظّم النطاقات المتاحة حسب نوع المورد:
لا تطلب إلا النطاقات التي يحتاج إليها تطبيقك فعليًا. سيرى المستخدمون الأذونات المطلوبة أثناء التفويض.

مسار رمز التفويض في OAuth 2.0

يطبّق Teable مسار رمز التفويض القياسي في OAuth 2.0:

الخطوة 1: إعادة توجيه المستخدمين إلى التفويض

وجّه المستخدمين إلى نقطة نهاية التفويض مع معلمات تطبيقك:
معلمات الاستعلام: مثال:

الخطوة 2: تفويض المستخدم

سيرى المستخدمون صفحة تفويض تعرض ما يلي:
  • اسم تطبيقك وشعاره
  • الأذونات المطلوبة (النطاقات)
  • خياري الموافقة على الوصول أو رفضه
إذا سبق للمستخدم تفويض تطبيقك (خلال 7 أيام افتراضيًا)، فستتم إعادة توجيهه فورًا من دون رؤية صفحة التفويض مرة أخرى.

الخطوة 3: معالجة معاودة الاتصال

بعد موافقة المستخدم (أو رفضه)، يعيد Teable التوجيه إلى عنوان URL لمعاودة الاتصال: عند النجاح:
عند الرفض:

الخطوة 4: استبدال الرمز برموز وصول

استبدل رمز التفويض برمز وصول ورمز تحديث:
نص الطلب: مثال على الطلب:
الاستجابة:

مسار التفويض باستخدام PKCE

صُمم PKCE (إثبات المفتاح لتبادل الرمز) للتطبيقات التي لا يمكنها تخزين سر العميل بأمان، مثل تطبيقات سطح المكتب الأصلية وتطبيقات الأجهزة المحمولة وأدوات CLI وتطبيقات الصفحة الواحدة.

الخطوة 1: إنشاء معلمات PKCE

قبل بدء التفويض، يحتاج العميل إلى إنشاء زوج من معلمات PKCE:

الخطوة 2: إعادة توجيه المستخدمين إلى التفويض

معلمات الاستعلام: مثال:
في وضع PKCE، يدعم redirect_uri عناوين الاسترجاع المحلي (http://127.0.0.1 وhttp://[::1] وhttp://localhost) مع مطابقة مرنة للمنافذ؛ فلا تحتاج إلى تسجيل كل منفذ بدقة.

الخطوة 3: معالجة معاودة الاتصال

كما في مسار رمز التفويض القياسي، يُعاد رمز التفويض عبر إعادة التوجيه بعد موافقة المستخدم.

الخطوة 4: استبدال الرمز وcode_verifier برموز وصول

نص الطلب:
لا يتطلب وضع PKCE القيمة client_secret. تُستخدم القيمة code_verifier بدلاً منها للتحقق من هوية العميل.
مثال على الطلب:
تنسيق الاستجابة مماثل لمسار رمز التفويض القياسي.

مسار تفويض الجهاز

يُستخدم منح تفويض الجهاز (RFC 8628) للعملاء الذين لا يمكنهم تلقي إعادة توجيه من المتصفح: مثل أداة CLI تعمل عبر SSH أو داخل حاوية أو في بيئة تطوير سحابية. يعرض عميلك عنوان URL ورمزًا قصيرًا، ويوافق المستخدم في أي متصفح، ولا يلزم إدخال أي شيء مجددًا في الطرفية. يتبع Teable معيار RFC 8628، لذا يمكن لمعظم مكتبات عميل OAuth تشغيل هذا المسار من دون شيفرة مخصصة. وفيما يلي ما يخص Teable تحديدًا.
يكون مسار الجهاز معطّلًا افتراضيًا. فعّل تمكين مسار الجهاز في إعدادات تطبيق OAuth قبل استخدامه. يمكن لأي شخص يعرف معرّف العميل بدء هذا المسار باسم تطبيقك، لذا لا تمكّنه إلا إذا كان تطبيقك يحتاج إليه. كما يؤدي تعطيله مرة أخرى إلى إيقاف الطلبات التي لا تزال بانتظار الموافقة.

طلب رمز جهاز

أرسل POST /api/oauth/device/code مع client_id وscope اختياري. نقطة النهاية مجهولة الهوية ومحدودة بمعدل 30 طلبًا لكل 15 دقيقة لكل عنوان IP.
تنتهي صلاحية كلا الرمزين بعد 15 دقيقة (BACKEND_OAUTH_DEVICE_CODE_EXPIRE_IN)، وتمثل interval الحد الأدنى لعدد الثواني الواجب انتظاره بين عمليات الاستقصاء. اعرض verification_uri وuser_code. في تلك الصفحة، يسجّل المستخدم الدخول ويدخل الرمز ويراجع اسم تطبيقك وصفحته الرئيسية ونطاقاته المطلوبة قبل الموافقة أو الرفض. تحذّره الصفحة من الموافقة على رمز لم يبدأ طلبه بنفسه. ولا يمكن استخدام كل رمز إلا مرة واحدة.
لا يُرجع Teable القيمة verification_uri_complete، وينبغي ألا ينشئ عميلك واحدة. يُسجّل الرمز الموافق عليه دخول الشخص الذي وافق إلى حسابه الخاص في Teable؛ ولذلك فإن الرابط الذي يحمل الرمز مسبقًا هو تحديدًا ما تعتمد عليه هجمات التصيد الاحتيالي لرمز الجهاز.

الاستقصاء عن رموز الوصول

أرسل POST /api/oauth/access_token مع grant_type=urn:ietf:params:oauth:grant-type:device_code وdevice_code وclient_id. لا يرسل العملاء العامّون client_secret، بينما يضيفه العملاء السريون كما في المسارات الأخرى. إلى أن يوافق شخص على الرمز، تستجيب نقطة النهاية بخطأ بدلاً من رموز الوصول: بعد موافقة المستخدم، تكون الاستجابة هي حمولة رموز الوصول نفسها المستخدمة في المسارات الأخرى.

استخدام رموز الوصول

ضمّن رمز الوصول في ترويسة Authorization لطلبات API:
تكون الخطوة الأولى بعد الحصول على رمز عادةً هي جلب جميع قواعد البيانات التي يمكن للمستخدم الحالي الوصول إليها:
تُرجع نقطة النهاية هذه جميع قواعد البيانات التي يملك المستخدم الحالي إذنًا للوصول إليها. ويمكنك استخدام baseId من الاستجابة في استدعاءات API اللاحقة.

تحديث رموز الوصول

عند انتهاء صلاحية رمز الوصول، استخدم رمز التحديث للحصول على رمز جديد:
نص الطلب: مثال على الطلب:
بعد التحديث، يصبح رمز التحديث السابق غير صالح (تدوير رمز التحديث). احفظ دائمًا رمز التحديث الجديد الوارد في الاستجابة.

إلغاء الوصول

لمالكي تطبيق OAuth

ألغِ وصول التطبيق لجميع المستخدمين (لا يمكن تنفيذ ذلك إلا بواسطة منشئ التطبيق):
يحذف ذلك جميع سجلات التفويض ورموز الوصول الخاصة بالمستخدمين، ويمنع التطبيق تمامًا من الوصول إلى بيانات أي مستخدم.

للمستخدمين

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

للتطبيقات

يمكن للتطبيقات إلغاء وصولها باستخدام رمز وصول:
لا تقبل نقطة النهاية هذه إلا المصادقة باستخدام رمز الوصول، وليس مصادقة الجلسة.

انتهاء صلاحية الرموز

معالجة الأخطاء

استجابات الأخطاء الشائعة:

أفضل الممارسات

  1. اختيار الوضع المناسب: استخدم وضع سر العميل لتطبيقات الويب ذات الخادم الخلفي، ووضع PKCE للتطبيقات الأصلية وأدوات CLI وتطبيقات الصفحة الواحدة، ومسار الجهاز عندما يتعذر على العميل تلقي إعادة توجيه من المتصفح
  2. حفظ الأسرار بأمان: لا تكشف سر العميل مطلقًا في الشيفرة من جانب العميل
  3. استخدام معلمة state: ضمّن دائمًا معلمة state عشوائية لمنع هجمات CSRF
  4. طلب الحد الأدنى من النطاقات: لا تطلب إلا الأذونات التي يحتاج إليها تطبيقك فعليًا
  5. معالجة تحديث الرموز: نفّذ تحديثًا تلقائيًا للرموز قبل انتهاء صلاحيتها
  6. تأمين تخزين الرموز: خزّن رموز الوصول والتحديث بأمان على خادمك

أمثلة كاملة

Node.js (رمز التفويض + سر العميل)

Python (وضع PKCE لأدوات CLI)

آخر تعديل في ٤ سبتمبر ٢٠٢٦