إعداد Google Cloud وOAuth

يمكن الوصول إلى Google Health API من خلال Google Cloud. لتفعيل واجهة برمجة التطبيقات والموافقة على حساب Google، يجب أن يكون لديك مشروع على Google Cloud.

سواء كنت مطوّرًا حاليًا في Fitbit API أو مستخدمًا جديدًا في Google Health API، عليك إكمال هذه الخطوة لإجراء طلبات إلى واجهة برمجة التطبيقات.

إنشاء مشروع وعميل OAuth

استخدِم الزر تفعيل واجهة برمجة التطبيقات والحصول على معرّف عميل OAuth 2.0 لتفعيل Google Health API والحصول على معرّف عميل OAuth 2.0:

1. إذا كان لديك مشروع حالي على Google Cloud تريد استخدامه في Google Health API، تأكَّد أولاً من تسجيل الدخول إلى حساب المشرف لهذا المشروع. بعد ذلك، اختَر المشروع الحالي من قائمة المشاريع المتاحة بعد النقر على الزر. وإلا، أنشِئ مشروعًا جديدًا.
2. اختَر خادم الويب عندما يُطلب منك تحديد "المكان الذي تجري منه الطلب".
3. أدخِل https://www.google.com كقيمة معرّفات الموارد المنتظمة (URI) لإعادة التوجيه المفوّضة. يجب توفير معرّف URI لإعادة التوجيه للحصول على رمز التفويض باستخدام OAuth 2.0.
4. بعد اكتمال عملية الإعداد، انسخ قيمتَي "معرّف عميل OAuth 2.0" و"سر العميل"، ونزِّل ملف JSON لبيانات الاعتماد على جهازك المحلي.

تفعيل واجهة برمجة التطبيقات والحصول على معرّف عميل OAuth 2.0

إذا أردت إعداد مشروعك على Google Cloud يدويًا أو التحقّق من الإعداد واسترداد بيانات الاعتماد مرة أخرى، اتّبِع الخطوات التالية:

1. فعِّل Google Health API في صفحة تفعيل واجهة برمجة التطبيقات.
2. احصل على معرّف عميل OAuth 2.0 في صفحة بيانات الاعتماد.

لمزيد من المعلومات حول إعداد OAuth 2.0 باستخدام وحدة تحكّم Google، يُرجى الاطّلاع على استخدام OAuth 2.0 للدخول إلى Google APIs.

إضافة مستخدمين للاختبار

تكون برامج OAuth التي تم إنشاؤها حديثًا في حالة لم يتم التحقّق منها، ويبلغ الحد الأقصى لعدد المستخدمين 100 مستخدم لأغراض الاختبار والإنتاج. لتفعيل التفويض خلال هذه الفترة، عليك إضافة عنوان البريد الإلكتروني لكل مستخدم يدويًا إلى قائمة "المستخدمون للاختبار" في إعدادات مشروعك.

عدِّل قائمة المستخدمين للاختبار في صفحة الجمهور:

1. في هذه الصفحة، من المفترض أن تظهر لك "حالة النشر" على أنّها الاختبار، و يظهر لك "نوع المستخدم" على أنّه خارجي.
2. ضمن القسم "المستخدمون للاختبار"، انقر على + إضافة مستخدمين. أدخِل عنوان البريد الإلكتروني لأي مستخدمين للاختبار يجب السماح لهم بمنح تطبيقك إذن الوصول إلى بياناتهم الصحية.
3. انقر على حفظ.

يتطلّب دعم أكثر من 100 مستخدم باستخدام Google Health API إكمال مراجعة أمان من جهة خارجية. يمكنك الاطّلاع على معلومات إضافية في مركز مساعدة التحقّق من تطبيق OAuth OAuth.

إضافة النطاقات

عليك تحديد النطاقات التي يُسمح لعميلك بطلبها في صفحة الوصول إلى البيانات:

1. في هذه الصفحة، انقر على إضافة نطاقات أو إزالتها.
2. في عمود "واجهة برمجة التطبيقات"، ابحث عن "Google Health API". اختَر النطاقات التي تحتاج إليها لتطبيقك.
3. بعد اختيار جميع النطاقات التي تحتاج إليها، انقر على تعديل للرجوع إلى صفحة "الوصول إلى البيانات".
4. انقر على حفظ.

قبل اختيار النطاقات، راجِع عملية تنفيذ النطاق .

لقد انتهيت من إعداد معرّف العميل، ويُفترض أن تتمكّن الآن من إجراء طلبات إلى Google Health API.

تعديل النطاقات

يمكنك مطالبة المستخدم بإعادة منح الإذن لتطبيقك من خلال ضبط المَعلمة `prompt` على `consent` في طلب المصادقة. عند تضمين prompt=consent، تظهر شاشة طلب الموافقة في كل مرة يطلب فيها تطبيقك تفويض نطاقات الوصول، حتى إذا تم منح جميع النطاقات سابقًا لمشروعك على Google APIs.

لإضافة نطاقات أو تغييرها باستخدام المَعلمة prompt=consent، اتّبِع الخطوات التالية:

1. حدِّد القائمة الكاملة بـ النطاقات التي يحتاج إليها تطبيقك. يجب أن يشمل ذلك النطاقات الحالية وأي نطاقات جديدة تحتاج إلى إضافتها.

2. عدِّل المَعلمة `scope` في عنوان URL الخاص بالتفويض لتضمين القائمة المعدَّلة بقيم النطاقات المفصولة بمسافات.

3. ألحِق prompt=consent بمعلَمات عنوان URI الخاص بالمصادقة. يفرض ذلك على خادم التفويض مطالبة المستخدم بالموافقة قبل عرض المعلومات على عميلك.

   يعرض المثال التالي طلب استرداد بيانات باستخدام GET عبر HTTPS إلى نقطة نهاية تفويض OAuth 2.0 من Google يطلب نطاقات متعددة مع إلحاق prompt=consent:

   https://accounts.google.com/o/oauth2/v2/auth?client_id=client-id&redirect_uri=redirect-uri&response_type=code&access_type=offline&scope=https://www.googleapis.com/auth/googlehealth.activity_and_fitness.readonly%20https://www.googleapis.com/auth/googlehealth.sleep.readonly&prompt=consent

4. عندما ينقر المستخدم على الرابط المعدَّل، ستظهر له صفحة موافقة تسرد جميع النطاقات المطلوبة. بعد أن ينقر المستخدم على "متابعة" أو "السماح"، ستتلقّى رمز تفويض جديدًا يمكن استبداله برموز مميّزة تغطي المجموعة الكاملة من النطاقات.

   لا تضمِّن prompt=consent إلا عند الضرورة، مثلاً عندما تحتاج إلى الحصول على الرمز المميز لإعادة التحميل أو عندما تكون النطاقات المطلوبة قد تغيّرت.

مكتبات عملاء OAuth2

يمكنك الاطّلاع على قائمة مكتبات عملاء OAuth2 المتاحة المستخدَمة للدمج مع الأطر الشائعة في استخدام OAuth 2.0 للدخول إلى Google APIs.

الرموز المميّزة لإعادة التحميل

للحفاظ على إمكانية الوصول إلى Google APIs على المدى الطويل بدون الحاجة إلى إعادة مصادقة المستخدم باستمرار، يجب أن يستخدم تطبيقك رمزًا مميّزًا لإعادة التحميل. للاطّلاع على تفاصيل التنفيذ الشاملة، بما في ذلك طلبات HTTP والمعلَمات المحدّدة المطلوبة، يُرجى الرجوع إلى مستندات Google Identity Platform.

لاستبدال رمز مميّز لإعادة التحميل برمز مميّز للوصول، عليك إجراء طلب HTTPS POST إلى نقطة نهاية الرمز المميّز لبروتوكول Google OAuth 2.0. يعرض المقتطف التالي مثالاً على الطلب والردّ:

طلب

curl -L -X POST 'https://oauth2.googleapis.com/token' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'client_id=client-id&client_secret=client-secret&refresh_token=refresh-token&grant_type=refresh_token'

الردّ

{
  "access_token": "access-token",
  "expires_in": 3599,
  "scope": "scope-list",
  "token_type": "Bearer",
  "refresh_token": "refresh-token",
  "refresh_token_expires_in": 112154
}

سلوك الرمز المميّز أثناء الاختبار

يُرجى العِلم بسلوك الرموز المميّزة لإعادة التحميل استنادًا إلى حالة النشر في مشروعك على Google Cloud:

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

لضمان تجربة مستخدم سلسة، احرص على نشر تطبيقك قبل نقله إلى بيئة التشغيل الفعلي لتجنُّب انتهاء صلاحية الرموز المميّزة بعد 7 أيام.

الحماية العابرة للحساب (RISC API)

فعِّل واجهة برمجة التطبيقات "مشاركة المعلومات والتنسيق بشأن المخاطر والحوادث" (RISC) إذا أردت تلقّي إشعارات بالتغييرات التي تطرأ على الرموز المميّزة للأحداث أو ربط الحسابات، مثل الحسابات غير المرتبطة أو الرموز المميّزة التي تم إبطالها، لتنظيف الرموز المميّزة المخزّنة وتعديل حالة الاتصال بواجهة المستخدم. إنّ تفعيل RISC API اختياري.

لتفعيل RISC API لمشروعك على Google Cloud، اتّبِع الخطوات التالية:

1. افتح صفحة RISC API في Google Cloud Console. تأكَّد من اختيار المشروع الذي تستخدمه في Google Health API.
2. اقرأ بنود RISC و تأكَّد من فهمك للمتطلبات.
3. انقر على تفعيل إذا كنت توافق على البنود.

بعد تفعيل واجهة برمجة التطبيقات، عليك إنشاء نقطة نهاية HTTPS وتسجيلها لتلقّي الرموز المميّزة للأحداث التي ترسلها Google والتحقّق من صحتها.

لمزيد من المعلومات حول الحماية العابرة للحساب وRISC، يُرجى الاطّلاع على حماية حسابات المستخدمين باستخدام ميزة "الحماية العابرة للحساب".