لضبط بروتوكول OAuth لتطبيقك، عليك إعداد سير عمل OAuth وتفعيل نطاقات OAuth في Data Portability API.
إعداد سير عمل OAuth
لإعداد عملية OAuth لتطبيقك، اتّبِع الخطوات الأساسية الواردة في مستندات Google Identity.
يستخدم معظم المطوّرين مسار تطبيقات الويب من جهة الخادم للحصول على موافقة OAuth، ولكن يمكنك أيضًا استخدام مسار تطبيقات الويب المستندة إلى JavaScript أو مسار تطبيقات الأجهزة الجوّالة وتطبيقات الكمبيوتر المكتبي.
يمكن أن تستغرق عمليات التصدير وقتًا أطول من مدة صلاحية رمز الوصول، أو يمكن للمستخدم منح إذن الوصول لمدة 30 أو 180 يومًا. قد تحتاج إلى الحصول على رمز مميّز لإعادة التحميل و استبداله برمز مميّز جديد للوصول بشكل دوري. لمزيد من التفاصيل، يُرجى الاطّلاع على إعادة تحميل رمز مميّز للوصول إلى تطبيقات الويب و إعادة تحميل رمز مميّز للوصول إلى تطبيقات الأجهزة الجوّالة وتطبيقات الكمبيوتر المكتبي.
ملاحظة مهمة: لا يتوفّر تجديد رمز OAuth للمستخدمين إلا إذا كانت حالة نشر العميل المستنِد إلى OAuth هي قيد الإصدار العلني، وليس قيد الاختبار. بالإضافة إلى ذلك، تنتهي صلاحية الرموز الممنوحة لعملاء OAuth الذين لديهم حالة نشر اختبار دائمًا بعد 7 أيام حتى إذا اخترت مدة 30 أو 180 يومًا. لمعرفة التفاصيل، يُرجى الاطّلاع على مقالة إعداد شاشة طلب الموافقة المتعلّقة ببروتوكول OAuth.
نطاقات OAuth لواجهة برمجة التطبيقات Data Portability API
عند ضبط تطبيق Data Portability API لاستخدام بروتوكول OAuth، فعِّل
نطاقات OAuth في Data Portability API ذات الصلة بتطبيقك. بعض النطاقات
هي sensitive
وrestricted
وتخضع لمتطلبات إضافية.
عند إضافة نطاقات Data Portability API إلى مسار OAuth، قد تكون هناك حالات يوافق فيها المستخدم على بعض النطاقات وليس كلها. يجب أن يكون تطبيقك قادرًا على التعامل مع هذه الحالات من خلال:
- السماح بعمليات تصدير البيانات الجزئية
- إشعار المستخدم بأنّه لم يحدّد جميع النطاقات اللازمة (و توقّف التطبيق بشكلٍ سلس)
- طلب الموافقات المتبقية من المستخدم
بالإضافة إلى ذلك، يختار المستخدم ما إذا كان سيمنحك إذن الوصول إلى بياناته لمرة واحدة أو لمدة 30 أو 180 يومًا.
- إذا منحك أحد المستخدمين إذن وصول لمرّة واحدة، يُسمح لتطبيقك بإجراء عملية واحدة لتصدير البيانات بموجب هذه الموافقة المحدّدة. لتنزيل البيانات مرة أخرى، تحتاج إلى موافقة جديدة من المستخدم.
- إذا منحك أحد المستخدمين إذن الوصول بالاستناد إلى الوقت، يُسمح لتطبيقك بتصدير البيانات مدّة زمنية محدّدة أو إلى أن يُبطل المستخدم الموافقة.
- يمكنك أيضًا اختيار تطبيق فلاتر زمنية على طلبك لتصدير البيانات لفترة زمنية محدّدة، مثل آخر 6 أشهر.
يُرجى العلم أيضًا أنّه خلال عملية OAuth، لا يعرف تطبيقك حساب Google الذي تم استخدامه لتقديم الموافقة. رمز OAuth الذي يتلقّاه تطبيقك غير شفاف.
للحصول على معلومات عن كيفية مشاركة المستخدمين للبيانات، اطّلِع على مقالة مشاركة نسخة من بياناتك مع جهة خارجية.
القيود المفروضة على النطاقات
يتناول هذا القسم القيود المفروضة على النطاقات التي تؤدي إلى ظهور أخطاء.
النطاقات المختلطة
لا يمكن خلط طلبات نطاق Data Portability API (مثل https://www.googleapis.com/auth/dataportability.*) مع نطاقات أخرى (مثل https://www.googleapis.com/auth/userinfo.email). في ما يلي مثال على طلب سيئ، مع وضع الجزء المحظور بخط عريض:
https://accounts.google.com/o/oauth2/v2/auth?
client_id=client_id &
redirect_uri=redirect_uri &
response_type=token&
scope=https://www.googleapis.com/auth/dataportability.myactivity.search+https://www.googleapis.com/auth/userinfo.email&
include_granted_scopes=false
النطاقات الممنوحة سابقًا
يجب عدم ضبط include_granted_scopes=true
مطلقًا عند طلب نطاقات DPAPI.
في ما يلي مثال على طلب غير صالح، مع وضع الجزء المحظور بخط عريض:
https://accounts.google.com/o/oauth2/v2/auth?
client_id=client_id &
redirect_uri=redirect_uri &
response_type=token&
scope=https://www.googleapis.com/auth/dataportability.myactivity.search&
include_granted_scopes=true
عدد كبير جدًا من النطاقات
إذا تم إلحاق عدد كبير جدًا من النطاقات بطلبك، قد تواجه خطأ
400 bad request
. ويحدث ذلك عندما يزداد طول عنوان URL عن الحدّ المسموح به في المتصفّحات. لحلّ هذه المشكلة، يمكنك تقسيم طلبات النطاقات إلى عدة
مجموعات أصغر واستخدام المصادقة المتزايدة لطلب
الموافقة على كل مجموعة.
فئات النطاقات
للحصول على قائمة بجميع نطاقات OAuth المتوافقة مع Data Portability API و فئاتها، يُرجى الاطّلاع على نطاقات OAuth المتاحة. للحصول على قائمة بجميع مجموعات موارد ونطاقات OAuth المتوافقة مع خدمة معيّنة، اطّلِع على صفحة مرجع المخطّط لتلك الخدمة.