1.1: קישור של חשבון OAuth
מבוא והשפעה על העסק
כדי להשתמש בממשקי Google API, נדרש OAuth כדי להעניק את השילוב את הגישה הדרושה למוכרים כדי לצרף אותם לכרטיסי מוצר חינמיים ולמודעות בתשלום.
כדי לאשר בקשות, האפליקציה חייבת להשתמש בפרוטוקול OAuth 2.0. אין תמיכה בפרוטוקולים אחרים של הרשאות.
הנחיות לגבי UX
יעד: לתת למוכרים הרשאה לשתף שימוש בנתונים שלהם עבור אפליקציית Google.
עקרון עיצוב: בקשו את ההרשאה הנכונה בזמן הנכון. אם המוכרים לא יתנו את ההרשאה, יש להיכשל בצורה חלקה.
המוֹכר מתבקש לספק הרשאות גישה. הנה דוגמה לאופן שבו ההוראות האלה יכולות להופיע למוכר:
אחרי שהמוכר עובר את השלבים הראשוניים האלה, יש שלוש תוצאות אפשריות:
תוצאה מס' 1: אם המוכר מסכים לכל ההרשאות:
אם המוכר נותן הרשאות מלאות, הוא מסמן את כל התיבות. ומתבקש להמשיך בתהליך ההצטרפות.
תוצאה מס' 2: אם המוכר לא מסכים ל-Google Ads
המוֹכר בודק את כל התיבות מלבד ההרשאה שקשורים ל-Google Ads. הם ממשיכים בתהליך הקליטה ולאחר מכן, כשהם יוצרים חשבון Google Ads חדש או מתחברים אל בחשבון קיים, הם יתבקשו שוב לתת הרשאות:
תוצאה מס' 3: אם הסימון של נתוני המוצרים או של האתר 'אימות האתר' לא מסומן, החשבון של המוכר לא יוכל להמשיך להצטרף
כל האפשרויות הקודמות מובילות לאותה הודעת שגיאה:
הנחיות טכניות
בחירת הבקשות לאישור עם OAuth 2.0
יש שתי שיטות לבחירת שיטת אימות של מוכר:
| OAuth 2.0 לחשבונות שאינם חשבונות שירות (מומלץ מאוד) | OAuth 2.0 לחשבונות שירות |
|---|---|
| לקוח OAuth 2.0 מזהה את האפליקציה ומאפשר למשתמשי קצה להעניק לאפליקציה גישה מוגבלת לנתוני Google שלהם. היא מאפשרת לאפליקציה לגשת לממשקי ה-API של Google Cloud בשם משתמש הקצה. המופעים הרשומים גורמים לביטול תוקף אסימון הגישה, שצריך להביא בחשבון את הגישה אליו בקוד: ● המשתמש ביטל את הגישה ● המשתמש שינה את הסיסמה ● מספר אסימוני הרענון שהוענקו חורג מהמגבלה ● אסימון הרענון לא היה בשימוש תוך 6 חודשים |
חשבונות שירות הם חשבונות Google מיוחדים, שאפליקציות יכולות להשתמש בהם כדי לגשת באופן פרוגרמטי ל-Google APIs באמצעות OAuth 2.0.הוא משתמש בתהליך OAuth 2.0 שאינו דורש הרשאה אנושית. במקום זאת, היא משתמשת בקובץ מפתח שרק האפליקציה שלך יכולה לגשת אליו. הערה: אפליקציות שמשתמשות בחשבונות שירות לאימות יכולות לגשת רק לחשבון Merchant Center שלהן. אם ברצונך לכתוב אפליקציית צד שלישי שזקוקה לגישה לחשבונות Merchant Center אפשר לעיין במדריך לבקשת הרשאה. הערה: נדרש פרויקט ב-Cloud שמאפשר ליצור עד 100 חשבונות שירות. לצפייה במסמכי התיעוד |
הגדרת תהליך OAuth
מסגרת הרשאה מסוג OAuth 2.0 מאפשרת לאפליקציה של צד שלישי לקבל גישה מוגבלת לשירות HTTP, מטעם בעלי המשאב על ידי תזמור אינטראקציה אישור בין בעלי המשאב לבין ה-HTTP בשירות, או על ידי מתן אפשרות לאפליקציה של צד שלישי לקבל גישה באופן עצמאי בשם.
מכיוון שהאפליקציה שלך ניגשת לנתונים מוגנים (לא ציבוריים), צריך להשתמש ב-OAuth 2.0 מזהה לקוח. ממשקי Google API משתמשים בפרוטוקול OAuth 2.0 לצורך אימות אישור. Google תומכת בתרחישים נפוצים של OAuth 2.0, כמו תרחישים באינטרנט השרת, האפליקציות המותקנות ובצד הלקוח.
מידע נוסף
דברים שחשוב לדעת לגבי שימוש ב-OAuth ל-Content API for Shopping:
חשוב לוודא שהגדרתם את סוג הגישה במצב אופליין: אסימוני גישה מדי פעם יפוגו פרטי כניסה לא חוקיים עבור ממשק API קשור בקשה.
רענון של אסימון גישה: אפשר לעשות זאת בלי להציג בקשה למשתמש לקבלת הרשאה (גם כשהמשתמש לא נוכח) אם ביקשת לקבל גישה אופליין להיקפים. שמשויך לאסימון (מידע נוסף).
הטמעת OAuth בספריות: מומלץ מאוד להשתמש ספריות הלקוח של Google API.
היקף: עליכם לבקש מהמוכר להעניק לכם קריאה וכן כתיבה לחשבון Google שלו באמצעות OAuth ב-Google Merchant Center היקף: https://www.googleapis.com/auth/content.
אפשר להשתמש ב-OAuth כדי לקבל מידע חשוב לגבי פרופיל המשתמש.
היקפי ההרשאות לשימוש בשילוב
בהתאם לסוג השילובים שאתם מתכננים ליצור כרגע, אנחנו ממליצים לבקש את כל היקפי ההרשאות הנדרשים.
| תוכנית | היקף | איזה פורמט נדרש היקף |
|---|---|---|
| Content API | https://www.googleapis.com/auth/content |
כרטיסי מוצר חינמיים |
| אימות האתר | https://www.googleapis.com/auth/siteverification |
כרטיסי מוצר חינמיים מודעות בתשלום |
| מודעות | https://www.googleapis.com/auth/adwords |
כרטיסי מוצר חינמיים מודעות בתשלום |
איך לבדוק אם המוכרים העניקו גישת OAuth
המוכרים צריכים לסמן תיבות בתהליך ההסכמה ל-OAuth כדי להעניק לך הרשאה גישה להיקפים ספציפיים: אם ההיקפים הנדרשים חסרים, מסבירים למוכרים למה הם נדרשים ואז לבקש שוב את ההרשאה (פרטים נוספים). אין גישה לכל ההרשאות האלה למנוע מהמוכרים להשלים את תהליך ההצטרפות באופן מלא.
קוראים לנקודת הקצה הבאה ב-API כדי לבדוק את היקפי ההרשאות שהוקצו:
https://www.oauth2.googleapis.com/token
כתובת ה-URL תחזיר את הפרטים הבאים:
- access_token
- היקפי הרשאות שניתנו למשתמש
- זמן לפני תפוגת האסימון
היקפי הרשאות רגישים ותהליך אימות OAuth
חלק מההיקפים שבהם נעשה שימוש בממשקי ה-API של OAuth נחשבים רגישים ודורשים תהליך אימות. מידע נוסף ודוגמאות מופיעות ב-OAuth ל-Content API.
היקף ההרשאות הרגיש של האפליקציה שתעמוד במדיניות: צריך לוודא שהאפליקציה עומדת בדרישות בהתאם למדיניות של Google בנושא נתוני משתמשים בשירותי API. עליך להסכים גם לתנאים ולהגבלות של ה-API.
מוודאים שהאפליקציה לא עומדת בדרישות של אף אחד מהתרחישים לדוגמה שמפורטים יוצאים מן הכלל לדרישות האימות.
אימות הבעלות על הדומיינים המורשים של הפרויקט: באמצעות החיפוש מסוף. צריך להשתמש בחשבון של בעלי הפרויקט או של התפקיד 'עריכת פרויקט' של הפרויקט במסוף Cloud.
יש לוודא שכל פרטי המיתוג במסך ההסכמה של OAuth תואמים חוקי, כמו: שם הפרויקט שמוצג למשתמשים, אימייל התמיכה, כתובת ה-URL של דף הבית כתובת ה-URL של מדיניות הפרטיות, מייצגת במדויק את זהות האפליקציה.
מבקשים מהאפליקציה להיקף חשיפה רגיש בתהליך האימות: לבצע את התהליך שמחייב מילוי טופס, מתן הצדקה ושליחת סרטון.