הגדרת OAuth לאפליקציה

כדי להגדיר את 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 שנתמכים בשירות מסוים מופיעה בדף העזר בנושא הסכימה של אותו שירות.