הגדרת Google Cloud ו-OAuth

הגישה ל-Google Health API ניתנת דרך Google Cloud. כדי להפעיל את ה-API ולאשר חשבון Google, צריך פרויקט ב-Google Cloud.

גם אם אתם מפתחים ותיקים של Fitbit API וגם אם אתם חדשים ב-Google Health API, תצטרכו להשלים את השלב הזה כדי לבצע קריאות ל-API.

יצירת פרויקט ולקוח OAuth

כדי להפעיל את Google Health API ולקבל מזהה לקוח של OAuth 2.0, לוחצים על הלחצן הפעלת ה-API וקבלת מזהה לקוח של OAuth 2.0:

1. אם יש לכם פרויקט קיים ב-Google Cloud שבו אתם רוצים להשתמש ב-Google Health API, ודאו שאתם מחוברים קודם לחשבון האדמין של הפרויקט הזה. אחרי שלוחצים על הלחצן, בוחרים את הפרויקט הקיים מתוך רשימת הפרויקטים הזמינים. אם לא, צריך ליצור פרויקט חדש.
2. כשמופיעה השאלה 'מאיפה מתקשרים?', בוחרים באפשרות Web Server (שרת אינטרנט).
3. מזינים את הערך https://www.google.com בשדה Authorized redirect URIs. כדי לקבל קוד הרשאה באמצעות OAuth 2.0, צריך להגדיר כתובת URI להפניה אוטומטית.
4. אחרי שמסיימים את ההגדרה, מעתיקים את הערכים של מזהה הלקוח וסוד הלקוח של OAuth 2.0 ומורידים את קובץ ה-JSON של פרטי הכניסה למחשב המקומי.

הפעלת ה-API וקבלת מזהה לקוח OAuth 2.0

אם רוצים להגדיר את הפרויקט ב-Google Cloud באופן ידני, או לאמת את ההגדרה ולאחזר שוב את פרטי הכניסה:

1. מפעילים את Google Health API בדף API Enablement.
2. מקבלים מזהה לקוח OAuth 2.0 בדף פרטי כניסה.

מידע נוסף על הגדרת OAuth 2.0 באמצעות מסוף Google זמין במאמר שימוש ב-OAuth 2.0 לגישה ל-Google APIs.

הוספת משתמשי בדיקה

כברירת מחדל, לקוחות OAuth שנוצרו לאחרונה נמצאים במצב לא מאומת, עם מגבלה של 100 משתמשים למטרות בדיקה וייצור. כדי להפעיל הרשאה במהלך התקופה הזו, צריך להוסיף באופן ידני את כתובת האימייל של כל משתמש לרשימת משתמשי הבדיקה בהגדרות הפרויקט.

מעדכנים את רשימת משתמשי הבדיקה בדף קהל:

1. בדף הזה, הסטטוס 'סטטוס הפרסום' צריך להיות בדיקה, והסטטוס 'סוג המשתמש' צריך להיות חיצוני.
2. בקטע 'משתמשי בדיקה', לוחצים על + הוספת משתמשים. מזינים את כתובת האימייל של משתמשי הבדיקה שרוצים לאפשר לאפליקציה לתת להם הרשאה לגשת לנתוני הבריאות שלהם.
3. לוחצים על שמירה.

כדי לתמוך ביותר מ-100 משתמשים באמצעות Google Health API, צריך להשלים בדיקת אבטחה של צד שלישי. מידע נוסף זמין במרכז העזרה בנושא אימות אפליקציות OAuth.

הוספת היקפי הרשאות

בדף גישה לנתונים, צריך לציין את היקפי ההרשאות שהלקוח יכול להפעיל:

1. בדף הזה, לוחצים על הוספה או הסרה של היקפי גישה.
2. בעמודה API, מחפשים את Google Health API. בוחרים את ההיקפים שדרושים לאפליקציה.
3. אחרי שבוחרים את כל ההיקפים שצריך, לוחצים על עדכון כדי לחזור לדף 'גישה לנתונים'.
4. לוחצים על שמירה.

סיימת להגדיר את מזהה הלקוח, ועכשיו אפשר לבצע קריאות ל-Google Health API.

עדכון היקפי ההרשאות

כדי לבקש מהמשתמש להעניק מחדש הרשאה לאפליקציה, צריך להגדיר את פרמטר ההנחיה consent בבקשת האימות. אם כוללים את prompt=consent, מסך ההסכמה מוצג בכל פעם שהאפליקציה מבקשת הרשאה להיקפי גישה, גם אם כל ההיקפים כבר הוענקו לפרויקט Google APIs.

כדי להוסיף או לשנות היקפי הרשאות באמצעות הפרמטר prompt=consent, פועלים לפי השלבים הבאים:

1. מזהים את הרשימה המלאה של ההיקפים שהאפליקציה צריכה. ההיקפים הקיימים וההיקפים החדשים שצריך להוסיף.

2. משנים את פרמטר ההיקף בכתובת ה-URL של ההרשאה כך שיכלול את הרשימה המעודכנת של ערכי ההיקף שמופרדים ברווחים.

3. מוסיפים את prompt=consent לפרמטרים של URI האימות. הפעולה הזו מאלצת את שרת ההרשאות לבקש מהמשתמש הסכמה לפני שהוא מחזיר מידע ללקוח.

   בדוגמה הבאה מוצגת בקשת HTTPS GET לנקודת הקצה של הרשאת 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.

אסימוני רענון

כדי לשמור על גישה לטווח ארוך לממשקי ה-API של Google בלי לדרוש אימות מחדש של המשתמש כל הזמן, האפליקציה שלכם צריכה להשתמש בטוקן רענון. פרטים מקיפים על ההטמעה, כולל בקשות ה-HTTP הספציפיות והפרמטרים הנדרשים, מופיעים במסמכי התיעוד של פלטפורמת הזהויות של Google.

כדי להחליף טוקן רענון בטוקן גישה, שולחים קריאת 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 ימים.