אישור

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

הרשאת בקשות

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

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

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

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

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

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

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

  1. כשאתם מפתחים את האפליקציה, צריך לרשום אותה באמצעות מסוף Google API. לאחר הרישום, Google מספקת נתונים שיהיו דרושים לכם מאוחר יותר, כמו מזהה לקוח וסוד לקוח.
  2. מפעילים את Analytics API במסוף Google API. (אם ממשק ה-API לא מופיע במסוף API, אפשר לדלג על השלב הזה).
  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.
  • פלאגין למערכת ניהול תוכן – היתרון של התהליך הזה בהשוואה לצד הלקוח או לשרת האינטרנט הוא שאפשר להשתמש בפרויקט יחיד במסוף API עבור האפליקציה. כך אפשר לקבל דיווח מאוחד והתקנה פשוטה יותר למשתמשים.

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

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

כדי להתחיל להשתמש ב-Analytics API, קודם כול צריך להשתמש בכלי ההגדרה. הכלי הזה מנחה אתכם בתהליך יצירת הפרויקט במסוף Google API, הפעלת ה-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. לאחר מכן תוכלו להשוות בין הבקשה וכותרות ה-HTTP מהאזור לבין מה שהאפליקציה שולחת אל Google Analytics. הבדיקה הזו היא דרך פשוטה לוודא שהבקשות שלכם בפורמט הנכון.

מענק לא תקין

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

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

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

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