אישור

במדריך הזה מוסבר איך אפליקציה מאשרת בקשות ל-User Deletion API.

אישור בקשות

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

כל הבקשות שהאפליקציה שולחת ל-Analytics API חייבות לכלול אסימון הרשאה. אסימון ההרשאה גם מזהה את האפליקציה שלכם ב-Google.

הסבר על פרוטוקולים של הרשאות

כדי לאשר בקשות, האפליקציה חייבת להשתמש בפרוטוקול OAuth 2.0. אין תמיכה בפרוטוקולים אחרים של הרשאות. אם האפליקציה משתמשת בכניסה באמצעות חשבון Google, היבטים מסוימים של ההרשאות מטופלים באופן אוטומטי.

הרשאת בקשות עם פרוטוקול OAuth 2.0

כל הבקשות ל-Analytics API חייבות להיות מאושרות על ידי משתמש מאומת.

הפרטים או ה"זרימה" של תהליך ההרשאה עם OAuth 2.0 עשויים להשתנות מעט, בהתאם לסוג האפליקציה שאתם מפתחים. התהליך הכללי הבא חל על כל סוגי האפליקציות:

  1. כשאתם מפתחים את האפליקציה, צריך לרשום אותה באמצעות Google API Console. לאחר הרישום, Google מספקת נתונים שיהיו דרושים לכם מאוחר יותר, כמו מזהה לקוח וסוד לקוח.
  2. מפעילים את Analytics API ב-Google API Console. (אם ה-API לא מופיע ב-API Console, אפשר לדלג על השלב הזה).
  3. כשהאפליקציה צריכה גישה לנתונים של משתמשים, היא מעבירה ל-Google בקשת גישה בהיקף ספציפי.
  4. Google מציגה למשתמש מסך הסכמה ומבקשת לאשר לאפליקציה לשלוח בקשה לחלק מהנתונים שלו.
  5. אם המשתמש מסכים, האפליקציה מקבלת מ-Google אסימון גישה לטווח קצר.
  6. האפליקציה מבקשת את נתוני המשתמש ומצרפת לבקשה את אסימון הגישה.
  7. אם Google תקבע שהבקשה והאסימון תקפים, היא תחזיר את הנתונים המבוקשים.

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

הפרטים לגבי היקפי OAuth 2.0 ב-Analytics API:

היקף משמעות
https://www.googleapis.com/auth/analytics.user.deletion מחיקת נתונים באמצעות User Deletion API.

כדי לבקש גישה באמצעות פרוטוקול OAuth 2.0, האפליקציה שלכם זקוקה למידע על ההיקף ולמידע ש-Google מספקת בזמן רישום האפליקציה (כמו מזהה לקוח וסוד לקוח).

טיפ: ספריות הלקוח של Google APIs יכולות לטפל בחלק מתהליך ההרשאה בשבילכם. הן זמינות במגוון שפות תכנות. פרטים נוספים זמינים בדף עם הספריות והדוגמאות.

תהליכי OAuth 2.0 נפוצים

הרשימה הבאה מציגה תרחישים נפוצים לשימוש בתהליכי OAuth 2.0 ספציפיים:

שרת אינטרנט

התהליך הזה מתאים לגישה אוטומטית, אופליין או מתוזמנת לנתוני Google Analytics של משתמש.

דוגמה:

  • עדכון אוטומטי של לוחות בקרה של משתמשים עם הנתונים העדכניים ביותר מ-Google Analytics.

צד הלקוח

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

דוגמה:

אפליקציות מותקנות

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

דוגמאות:

  • ווידג'ט לשולחן העבודה במחשב PC או Mac.
  • תוסף למערכת ניהול תוכן (CMS) – היתרון של התהליך הזה בהשוואה לשרת אינטרנט או לצד הלקוח הוא שאפשר להשתמש בפרויקט יחיד במסוף API עבור האפליקציה. כך אפשר לקבל דוחות מאוחדים ולהתקין את האפליקציה בצורה פשוטה יותר למשתמשים.

חשבונות שירות

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

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

כדי להגדיר חשבון שירות חדש:

  1. לוחצים על Create credentials > Service account key (יצירת אמצעי אימות > מפתח לחשבון שירות).
  2. בוחרים אם להוריד את המפתח הציבורי או הפרטי של חשבון השירות כקובץ P12 רגיל, או כקובץ JSON שאפשר לטעון באמצעות ספריית לקוח של Google API.

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

פתרון בעיות

ההרשאה נכשלת במצבים הבאים:

  • אם 401 פג התוקף של access_token או אם אתם משתמשים בהיקף שגוי עבור ה-API, תקבלו קוד סטטוס.

  • אם למשתמש המורשה אין גישה לתצוגה המפורטת (פרופיל), תקבלו קוד סטטוס 403. מוודאים שאתם מורשים עם המשתמש הנכון ושיש לו גישה לתצוגה המפורטת (פרופיל) שבחרתם.

OAuth 2.0 playground

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

מענק לא חוקי

כשמנסים להשתמש בטוקן רענון, מוחזרת השגיאה invalid_grant:

אפליקציות יכולות לבקש כמה טוקנים לרענון כדי לגשת לחשבון Google Analytics אחד.

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

המגבלה לכל זוג ייחודי של לקוח OAuth 2.0 וחשבון Google Analytics היא 25 טוקנים לרענון. אם האפליקציה ממשיכה לבקש טוקנים לרענון עבור אותו צמד של לקוח/חשבון, אחרי הנפקת הטוקן ה-26, הטוקן הראשון לרענון שהונפק בעבר יפסיק להיות תקף. הטוקן ה-27 לרענון שיישלח יבטל את הטוקן השני שהונפק בעבר, וכן הלאה.