דף זה תורגם על ידי Cloud Translation API.

אימות והרשאה בפרוטוקול הנתונים של Google

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

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

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

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

שירותי אימות והרשאה מכונים לעיתים קרובות auth.

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

כניסה באמצעות חשבון Google מאפשרת לאנשים להשתמש בקלות בפרטי הכניסה שלהם ב-Google כדי להיכנס לאתר. היא כוללת קבוצת כלים שקל לשלב במכשירים שונים.
OAuth 2.0 הוא פרוטוקול הרשאה לכל ממשקי Google API. OAuth 2.0 מסתמך על SSL מטעמי אבטחה, במקום לדרוש מהאפליקציה לבצע חתימה קריפטוגרפית באופן ישיר. פרוטוקול זה מאפשר לאפליקציה לבקש גישה לנתונים המשויכים לחשבון Google של משתמש.
התחברות באמצעות OAuth 2.0 (OpenID Connect) מאמתת את המשתמשים בכך שהם מתחברים באמצעות חשבונות Google שלהם. מדובר בהחלפה עבור OpenID, ומשתמשים של OpenID אמורים לעבור להשתמש ב-Login 2.0 כדי למנוע התחברות.

אם האפליקציה שלך היא גאדג'ט (לשימוש ב-IAB או במאגרים אחרים של OpenSocial), עיין בקטע אימות לגאדג'טים.

הערה: המסמך הזה מספק סקירה כללית של כל שיטת אימות. למידע מפורט על כל שיטה, עיין בתיעוד המלא של ממשקי API לאימות של חשבון Google.

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

OAuth - הרשאה לאפליקציות אינטרנט ולאפליקציות מותקנות

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

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

OAuth 2.0 לאפליקציות אינטרנט ולאפליקציות מותקנות

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

OAuth 1.0 ליישומי אינטרנט

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

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

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

שימוש ב-OAuth עם אפליקציות אינטרנט

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

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

תהליך ההרשאות של OAuth

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

ברמה בסיסית, התהליך הוא כך:

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

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

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

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

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

הכנה ל-OAuth

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

להחליט אם לרשום את אפליקציית האינטרנט שלך

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

על האפליקציה שלך לחתום על כל בקשת OAuth שהיא שולחת. אם ברצונך להשתמש בחתימה RSA-SHA1 כדי לחתום על בקשות, עליך להעלות אישור אבטחה כחלק מתהליך הרישום.

לחלופין, ניתן להשתמש בחתימת HMAC-SHA1 כדי לחתום על הבקשות. אין צורך באישור עבור חתימות HMAC-SHA1. במקום זאת, Google יוצרת ערך consumer secret של OAuth, שמוצג בדף הרישום של הדומיין לאחר הרישום.

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

קביעת היקף הנתונים שהאפליקציה שלך תיגש אליהם

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

באופן כללי, יש לבקש אסימון עבור ההיקף הצר ביותר שכולל את הנתונים הדרושים לך. לדוגמה, אם האפליקציה שלך דורשת גישה אל הפיד של 'כל היומנים' של המשתמש, עליך לבקש אסימון עבור ההיקף http://www.google.com/calendar/feeds/default/allcalendars/full.

הגדרת מנגנון לניהול אסימוני OAuth

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

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

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

הגדרת מנגנון לבקשת גישה לשירות Google

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

למידע נוסף על פורמט הבקשה המתאים לכל Google Data API, יש לעיין במסמכי התיעוד של אותו API.

הטמעה של OpenID (אופציונלי)

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

עבודה עם אסימוני OAuth

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

קבלת אסימון בקשה לא מורשה (OAuthGetRequestToken)
נותנים הרשאה לאסימון הבקשה (OAuthAuthorizeToken)
החלפת אסימון הבקשה המאושר של אסימון גישה (OAuthGetAccessToken)

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

אפשר לערוך ניסויים ולבקש אסימוני הרשאה במגרש המשחקים של OAuth.

למידע נוסף, ניתן לעיין בחומר העזר בנושא OAuth API.

הגדרת כתובת URL לקריאה חוזרת (callback)

אפשר לציין ערך בשדה oauth_callback בבקשה OAuthGetRequestToken כדי לקבוע את המיקום שאליו Google מפנה את המשתמש לאחר שהוא יאשר את בקשת הגישה שלך. כתובת ה-URL לקריאה חוזרת (callback) יכולה לכלול פרמטרים של שאילתה. ההפניה האוטומטית תכלול את אותם פרמטרים של שאילתה, וגם את אסימון הבקשה המורשה, שהאפליקציה שלך חייבת להיות מסוגלת לנתח.

לדוגמה, אם אתם תומכים בשפות מרובות, אפשר לכלול פרמטר של שאילתה, שמזהה את גרסת האפליקציה שהמשתמש צופה בה. ערך oauth_callback של "http://www.yoursite.com/Fetchtoken?Lang=de יגרום להפניה מחדש "http://www.yoursite.com/Fetchtoken?Lang=de&oauth_token=DQAADKEDE". ניתוח האסימון והפרמטר של השפה מבטיח שהמשתמש יופנה בחזרה לגרסה הנכונה של האתר.

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

זיהוי האפליקציה שלך למשתמשים

Google מציגה בדרך כלל את השם של אפליקציה כשמבקשים מהמשתמשים הסכמה לקבלת גישה (למידע נוסף).

אם הבקשה שלך לא רשומה, יש להשתמש בפרמטר xoauth_displayname בבקשה OAuthGetRequestToken כדי לציין את שם הבקשה. אם לא תציינו את הפרמטר הזה, Google תציג את שם הדומיין של כתובת ה-URL שסופק על ידי הפרמטר oauth_callback. אם לא תספקו כתובת URL לקריאה חוזרת (callback), Google תציג את המחרוזת "אנונימית".

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

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

עבודה עם דומיינים של Google Apps

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

מידע נוסף על OAuth

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

שימוש ב-OAuth עם ספריות הלקוח של Google Data APIs
מאמר: שימוש ב-OAuth עם ממשקי ה-API של נתונים של Google, כולל תיאור של 'מגרש המשחקים של OAuth', כלי אינטראקטיבי להתנסות ב-OAuth.
OAuth עבור יישומי אינטרנט (תיעוד מלא)
הרשמה לאפליקציות מבוססות אינטרנט
יצירת מפתחות ואישורים
מפרט OAuth

חזרה למעלה

שימוש ב-OAuth עם אפליקציות מותקנות

כל ממשקי ה-API של נתוני Google תומכים ב-OAuth, תקן פתוח לאישור השימוש בנתונים באפליקציות. כדי להשתמש ב-OAuth, צריך לרשום אפליקציות מותקנות ב-Google.

תהליך ההרשאות של OAuth

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

ברמה בסיסית, התהליך הוא כך:

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

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

OAuth תומך באפליקציות מותקנות שמשתמשות במצב 'לא רשום'. יש שיטות שונות לקבלת אסימון בקשה מורשה, ולכן האפליקציה יכולה להשתמש ב-OAuth כדי לתת הרשאה לאפליקציה גם אם למכשיר שבו היא מותקנת אין דפדפן אינטרנט.

הכנה ל-OAuth

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

קביעת היקף הנתונים שהאפליקציה שלך תיגש אליהם

הגדרת מנגנון לניהול אסימוני OAuth

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

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

הגדרת מנגנון לבקשת גישה לשירות Google

למידע נוסף על פורמט הבקשה המתאים לכל Google Data API, יש לעיין במסמכי התיעוד של אותו API.

עבודה עם אסימוני OAuth

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

קבלת אסימון בקשה לא מורשה (OAuthGetRequestToken)
נותנים הרשאה לאסימון הבקשה (OAuthAuthorizeToken)
החלפת אסימון הבקשה המאושר של אסימון גישה (OAuthGetAccessToken)

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

אפשר לערוך ניסויים ולבקש אסימוני הרשאה במגרש המשחקים של OAuth.

למידע נוסף, ניתן לעיין בחומר העזר בנושא OAuth API.

זיהוי האפליקציה שלך למשתמשים

Google מציגה בדרך כלל את השם של אפליקציה כשמבקשים מהמשתמשים הסכמה לקבלת גישה (למידע נוסף).

יש להשתמש בפרמטר xoauth_displayname בבקשה OAuthGetRequestToken שלך כדי לציין את שם האפליקציה. אם לא תציינו את הפרמטר הזה, Google תציג את שם הדומיין של כתובת ה-URL שסופק על ידי הפרמטר oauth_callback. אם לא תספקו כתובת URL לקריאה חוזרת (callback), Google תציג את המחרוזת "אנונימית".

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

הפעלת דפדפן אינטרנט

כחלק מתהליך ההרשאה ל-OAuth, האפליקציה שלך חייבת להגיש בקשת OAuthAuthorizeToken. המשתמש חייב להתחבר לדף אינטרנט של Google ולאשר את בקשת הגישה של האפליקציה.

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

מצב זיהוי אוטומטי

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

במצב הזה צריך לציין כתובת URL לקריאה חוזרת (callback) שאליה המשתמש מופנה אחרי שהוא יאשר את בקשת הגישה. יש לספק את כתובת האתר הזו כפרמטר oauth_callback של הבקשה OAuthGetRequestToken, וכפרמטר verifier של הבקשה OAuthGetAccessToken.

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

מידע נוסף ושיטות מומלצות זמינים במאמר אישור זיהוי אוטומטי.

אם האפליקציה לא מצליחה לזהות באופן אוטומטי כשלמשתמש יש הפניה אוטומטית לכתובת ה-URL לקריאה חוזרת, או כשהיא לא יכולה להציג את עצמה בחזית, כתובת ה-URL לקריאה חוזרת (callback) אמורה להציג דף שמסביר איך להעביר את האפליקציה לחזית ואת הבקשה להפעלת הבקשה OAuthGetAccessToken מתוך האפליקציה.

מצב המכשיר

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

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

מצב פיתוח

מצב זה מומלץ לשימוש במהלך פיתוח מוקדם של אפליקציה בלבד.

במצב 'זיהוי אוטומטי', האפליקציה צריכה להפעיל דפדפן והמשתמש חייב לאשר את הבקשה. עם זאת, במקום ליצור דף אינטרנט עבור כתובת ה-URL לקריאה חוזרת (callback), אפשר להגדיר את הערך של הפרמטר oauth_callback ל-"oob" (מחוץ לפס).

במקרה כזה, אחרי שהמשתמש יאשר את הבקשה, Google תפנה את המשתמשים לדף של חשבונות Google שבו מופיע מספר האימות (ראו דוגמה).

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

מידע נוסף על OAuth

שימוש ב-OAuth עם ספריות הלקוח של Google Data APIs
מאמר: שימוש ב-OAuth עם ממשקי ה-API של נתונים של Google, כולל תיאור של 'מגרש המשחקים של OAuth', כלי אינטראקטיבי להתנסות ב-OAuth.
OAuth עבור אפליקציות מותקנות (תיעוד מלא)
יצירת מפתחות ואישורים
מפרט OAuth

חזרה למעלה

שימוש ב-AuthSub להרשאה

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

תהליך ההרשאה ל-AuthSub

תהליך ההרשאה ב-AuthSub כולל רצף של אינטראקציות בין שלוש ישויות: אפליקציית האינטרנט, שירותי Google והמשתמש. התרשים הזה ממחיש את הרצף:

תהליך ההרשאה

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

עבודה עם AuthSub

שילוב AuthSub באפליקציית האינטרנט מחייב את המשימות הבאות:

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

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

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

לחלופין, תוכלו לבחור לקבל אסימונים עדכניים באופן קבוע, כל עוד הגדרתם מנגנון לביטול אסימון. כדי לבטל את האסימון הקיים, האפליקציה שלך צריכה לבטל את האסימון הקיים. בתרחיש הזה, המשתמש יידרש להתחבר ולהעניק גישה בכל פעם שיתבקש אסימון חדש.
הגדרת ההיקף הנדרש על ידי שירות Google כדי לקבל גישה.
כל שירות של Google קובע את כמות הגישה ואת סוג הגישה. הגישה הזו מוצגת כערך היקף. היקף השירות עשוי להיות כתובת URL פשוטה שמזהה את השירות בשלמותו, או שהוא עשוי לציין גישה מוגבלת יותר. חלק מהשירותים מגבילים מאוד את הגישה, למשל מאפשרים גישה לקריאה בלבד למידע מוגבל. כדי לקבל את היקפי השירות המותרים עבור שירות Google שאליו ברצונך לגשת, עיין במסמכים עבור שירות זה. יש לבקש את האסימון בעל ההיקף הגבוה ביותר האפשרי. לדוגמה, אם אתם מנסים לגשת לתכונה של פיד Atom של Gmail, עליכם להשתמש בהיקף "http://www.google.com/calendar/feeds/ ", ולא ב-"http://www.google.com/calendar/ ". בשירותי Google יש הרבה יותר הגבלות על בקשות בהיקף רחב.
צריך להגדיר מנגנון כדי לבקש ולקבל אסימון הרשאה.
המנגנון צריך ליצור קריאת AuthSubRequest תקינה, כולל ציון הערכים המתאימים של הבא והיקף כתובת ה-URL (כפי שנקבע בשלב 3). אם אתם משתמשים באסימונים מאובטחים ו/או מנהלים אסימוני סשנים, הבקשה צריכה לכלול גם ערכים למשתנים האלה.

כתובת ה-URL הבאה עשויה לכלול פרמטרים של שאילתה. לדוגמה, כשאתם תומכים בשפות מרובות, כוללים פרמטר שאילתה שמזהה את גרסת אפליקציית האינטרנט שהמשתמש צופה בה. אם הערך הבא יהיה http://www.yoursite.com/Retrievetoken?Lang=de, תתבצע הפניה אוטומטית http://www.yoursite.com/Retrievetoken?Lang=de&token=DQAADKEDE. ניתוח האסימון והפרמטר Lang מבטיח שהמשתמש יופנה חזרה לגרסה הנכונה של האתר.

בנסיבות מסוימות, השימוש בפרמטר hd יכול לייעל את חוויית המשתמשים שלך כשהם מתבקשים להעניק גישה באתר חשבונות Google. ברוב המקרים, תהליך הוא התחברות פשוטה לחשבון ובחירה אם להעניק גישה או לא. עם זאת, אם למשתמשים יש יותר מחשבון Google אחד (חשבון Gmail רגיל ו/או חשבון מתארח אחד או יותר ב-Google Apps), יהיה עליהם לבצע את תהליך ההתחברות הנוסף כדי לזהות לאיזה חשבון הם רוצים לגשת. אם האפליקציה שלך מיועדת לדומיין מנוהל אחד, ניתן לבטל את השלבים הנוספים האלה באמצעות הפרמטר הזה כדי לזהות את הדומיין. תוכל גם להשתמש בפרמטר hd אם האפליקציה שלך ניגשת לשירותים שאינם זמינים בחשבונות מתארחים – הגדרת הערך 'default' תגביל את ההרשאה לחשבונות רגילים בלבד. כשהערך hd מוגדר, Google תבחר אוטומטית את החשבון הנכון להרשאה.

יש צורך להשתמש במנגנון האסימון כדי לנתח את ההפניה האוטומטית שהתקבלה מ-Google, המכילה את האסימון לשימוש חד-פעמי ולבצע את הפעולות הנדרשות. מאחר שאסימוני ההרשאות הם ספציפיים למשתמש, האפליקציה שלך צריכה להיות מסוגלת לשייך אסימון למשתמש שלה. האפשרות המועדפת היא להנפיק קובץ cookie למשתמש לפני ביצוע בקשת האסימון. לאחר מכן, כש-Google תפנה את המשתמש בחזרה לאתר שלך באמצעות אסימון מצורף, האפליקציה שלך תוכל לקרוא את קובץ ה-cookie ולשייך את האסימון למזהה המשתמש הנכון.
אפשר להגדיר מנגנונים כדי לבקש אסימוני סשנים, ולשמור או לבטל אותם, אם רלוונטי.
בהתאם להחלטות שקיבלתם בנוגע לניהול האסימון בשלב 2, ייתכן שתצטרכו ליצור מנגנונים כדי לקבל ולבטל אסימוני סשנים (AuthSubSessionToken ו-AuthSubRevokeToken). כדי לבדוק סשנים של ביטול וביטול, יש להשתמש ב-AuthSubTokenInfo. הערך הזה מציין אם האסימון תקף או לא. אם מאחסנים אסימונים, האפליקציה חייבת לעקוב גם אחר מזהה המשתמש וגם עם השירות (היקף) שמכוסה על ידי האסימון.
הגדרת מנגנון לבקשת גישה לשירות Google.
אפשר להיעזר במסמכים של שירות Google כדי לקבל מידע על פורמט הבקשה. כל הבקשות לשירות Google חייבות לכלול אסימון הרשאה תקף. באופן כללי, בקשה לשירות Google היא בצורה של HTTP GET (או POST אם כותבים נתונים חדשים), כאשר האסימון מופיע בכותרת הבקשה.

כותרת הבקשה צריכה להופיע באופן הבא:
```
Authorization: AuthSub token="token"
```
כאשר token הוא אסימון ההרשאה, שימוש יחיד או ביקור, שהתקבל מ-Google בתגובה לבקשת AuthSub. אם האסימון מאובטח, חייבים לצרף לו חתימה דיגיטלית. להוראות ולדוגמאות, אפשר לעיין ב'בקשות לחתימה.

בדוגמה הבאה מוצגת כותרת של בקשה לשיחה לשירות הפיד של יומן Google. הבקשה הזו מכילה אסימון לא מאובטח:
```
GET /calendar/feeds/default/private/full HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AuthSub token="GD32CMCL25aZ-v____8B"
User-Agent: Java/1.5.0_06
Host: www.google.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
```

מידע נוסף על AuthSub

למידע נוסף על AuthSub, כולל רישום היישום שלך ב-Google והסבר מפורט על החלפת אסימון חד-פעמי באסימון הפעלה, עיין במקורות נוספים אלה:

אימות AuthSub עבור יישומי אינטרנט (תיעוד מלא)
שימוש ב-AuthSub עם ספריות הלקוח של Google Data APIs
יצירת מפתחות ואישורים (AuthSub מאובטח)
חתימת בקשות באמצעות AuthSub (פרוטוקול מאובטח AuthSub)
הרשמה לאפליקציות מבוססות אינטרנט

חזרה למעלה

שימוש ב-ClientLogin להרשאות

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

אימות עבור אפליקציות מותקנות: ClientLogin

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

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

תהליך ההרשאה של ClientLogin

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

תהליך ההרשאה

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

שימוש ב-ClientLogin

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

שילוב של ClientLogin באפליקציה שלכם מחייב את המשימות הבאות:

יוצרים רכיב בממשק המשתמש כדי לקבל נתוני התחברות מהמשתמש.
ממשק המשתמש צריך לבקש שם משתמש (כתובת אימייל כולל דומיין) וסיסמה. בנוסף, ממשק המשתמש אמור להיות מסוגל להציג תמונת CAPTCHA באמצעות כתובת האתר שמתקבלת מ-Google, אם נדרשת כזו, ובקשה של המשתמש לספק תשובה נכונה. באופן אידיאלי, ממשק המשתמש יכלול קישור לדף ההתחברות לחשבונות Google ('https://www.google.com/accounts/Login') במקרה שהמשתמש צריך להירשם לחשבון חדש או לבצע פעולות תחזוקה אחרות בחשבון.
צריך לכתוב קוד כדי ליצור בקשת HTTPS POST ClientLogin במבנה תקין ולהעביר אותה.
קוד זה צריך להכיל לוגיקה לטיפול באתגר CAPTCHA ולכלול את הפרמטרים logintoken ו-logincaptcha. האפליקציה אמורה גם להיות מסוגלת לזהות מתי המשתמש משמיט מידע נדרש, או לחזור על נתונים שגויים לאחר כשל בהתחברות, ולהציג שגיאה מבלי לשלוח בקשה מיותרת.
ניהול תגובות מ-Google.
קיימות ארבע תשובות אפשריות לבקשת התחברות:
- הצלחה (HTTP 200)
- כשל (HTTP 403) עם קוד שגיאה שמסביר
- בקשה לא חוקית, בדרך כלל כתוצאה מבקשה שגויה
- נכשל באתגר CAPTCHA
תגובת הצלחה מכילה אסימון הרשאה בשם "Auth". יש לכלול את האסימון בכל הבקשות הבאות לשירות Google של החשבון הזה. יש להגן היטב על אסימוני ההרשאות ואין לתת אותם לאף אפליקציה אחרת מאחר שהם מייצגים גישה לחשבון של המשתמש. מגבלת הזמן על האסימון משתנה בהתאם לשירות שהנפיק אותה.

תגובת הכישלון כוללת קוד שגיאה אחד או יותר וכתובת URL עם הודעת השגיאה שמוצגת למשתמש. לתשומת ליבכם: ClientLogin לא מבדיל בין שגיאה בגלל סיסמה שגויה לבין סיסמה שגויה עקב שם משתמש לא מזוהה (למשל, אם המשתמש עדיין לא נרשם לחשבון). האפליקציה שלך צריכה לטפל בכל הודעות השגיאה האפשריות לפי הצורך.
תגובת כשל עם אתגר CAPTCHA מציינת כי Google החליטה, מכל סיבה שהיא, לנקוט אמצעי אבטחה נוספים. התגובה הזו מלווה בכתובת URL של תמונת CAPTCHA ובאסימון שמייצג את האתגר הספציפי של CAPTCHA.
באמצעות Google אתם יכולים להתמודד עם אתגר CAPTCHA.
כדי להתמודד עם האתגר, האפליקציה חייבת להציג את תמונת ה-CAPTCHA ולבקש תשובה מהמשתמש. כדי להציג תמונת CAPTCHA, השתמש בערך CaptchaUrl המוחזר בתגובה לכשל, כשלפניו מופיעה כתובת האתר של חשבונות Google: "http://www.google.com/accounts/". לאחר שהמשתמש מספק תשובה, האפליקציה צריכה לשלוח שוב את בקשת ההתחברות, והפעם לכלול את אסימון ה-CAPTCHA (logintoken) ותשובת המשתמש (logincaptcha). Google מאמתת את התשובה של המשתמש לפני מתן הרשאת גישה לחשבון.

יש חלופה למפתחים שלא רוצים לנהל את התהליך של קבלה ושידור של תגובת משתמש ל-CAPTCHA. בתגובה לאתגר CAPTCHA, האפליקציה יכולה להפנות את המשתמש לדף שמתארח ב-Google : "https://www.google.com/accounts/DisplayUnlockCaptcha". לאחר שהמשתמש מגיב בהצלחה לאתגר, שרת Google נותן אמון במחשב שבו הוא משתמש. לאחר מכן, האפליקציה יכולה לשלוח מחדש את בקשת ההתחברות המקורית כדי לקבל את אסימון ההרשאה.

הערה: Google לא מאמתת את ניסיון ההתחברות לפני שליחת אתגר CAPTCHA. כלומר, ניסיון התחברות עלול להיכשל גם לאחר אתגר CAPTCHA.

* CAPTCHA הוא סימן מסחרי של אוניברסיטת קרנגי מלון

חזרה למעלה

אימות לגאדג'טים

Proxy ל-OAuth

אם אתה בונה גאדג'ט באמצעות ממשק ה-API לגאדג'טים הסטנדרטי, תוכל למנף תכונה של פלטפורמת הגאדג'ט שנקראת שרת proxy של OAuth כדי לגשת לממשקי API של נתונים של Google. OAuth (כמתואר למעלה) הוא תקן אימות שמאפשר למשתמשים לגשת לנתונים הפרטיים שלהם בשירות אירוח גאדג'טים כמו iGoogle, Shopify או Orkut, או לשתף את הנתונים שלהם עם אתר או גאדג'ט אחר. שרת ה-proxy של OAuth נועד להקל על מפתחי גאדג'טים את הפיתוח על ידי הסתרת פרטי האימות הרבים של OAuth. שרת ה-proxy מבוסס על פרויקט קוד פתוח בשם Shindig, שהוא יישום של מפרט הגאדג'ט.

הערה: שרת ה-proxy של OAuth נתמך רק בגאדג'טים שמשתמשים ב-API של gadgets.* ופועלים בקונטיינרים של OpenSocial. הוא לא נתמך ב-API לגאדג'טים מדור קודם.

תהליך האימות

הגאדג'ט שלך חייב לקבל אסימון OAuth לפני שיוכל לגשת לנתוני המשתמש. שרת ה-proxy של OAuth מנהל עבורך את תהליך האימות. בפעם הראשונה שמשתמש מתקין את הגאדג'ט שלך, מתקיים התהליך הבא:

הגאדג'ט שלך נטען בפעם הראשונה ומנסה לגשת לנתוני המשתמש דרך אחד מממשקי ה-API של Google Data.
הבקשה נכשלה כי לא ניתנה הרשאת גישה למשתמש. אובייקט התשובה מכיל כתובת URL (ב-response.oauthApprovalUrl) של דף אישור ה-OAuth. הגאדג'ט שלך צריך לספק שיטה להשקת חלון חדש עם כתובת האתר הזו.
בדף האישור, המשתמש בוחר להעניק או לדחות גישה לגאדג'ט שלך. אם הפעולה הצליחה, המשתמש מועבר לדף oauth_callback שאתה מציין. כדי ליהנות מחוויית השימוש הטובה ביותר, מומלץ להשתמש באפליקציה http://oauth.gmodules.com/gadgets/oauthcallback.
לאחר מכן המשתמש סוגר את החלון הקופץ. כדי להודיע לגאדג'ט שהמשתמש אישר, ניתן להשתמש במטפל בחלון קופץ כדי לזהות את סגירת חלון האישור. לחלופין, הגאדג'ט שלך יכול להציג קישור (לדוגמה, "אישרתי גישה") שעליו המשתמש יוכל ללחוץ לאחר סגירת החלון הזה.
הגאדג'ט שלך מנסה לגשת ל-Google Data API בפעם השנייה על ידי בקשת נתוני המשתמש מחדש. ניסיון זה בוצע בהצלחה.
הגאדג'ט שלך מאומת ויכול להתחיל לפעול כרגיל.

הגדרת גאדג'ט

כדי לגשת לממשק API אחד או יותר של Google Data, עליך לומר תחילה לגאדג'ט להשתמש ב-OAuth כשיטת האימות. יש להוסיף רכיב <OAuth> בקטע <ModulePrefs> ב-XML של הגאדג'ט שלך:

<ModulePrefs>
...
<OAuth>
  <Service name="google">
    <Access url="https://www.google.com/accounts/OAuthGetAccessToken" method="GET" />
    <Request url="https://www.google.com/accounts/OAuthGetRequestToken?
                  scope=http://www.blogger.com/feeds/%20http://www.google.com/calendar/feeds/" method="GET" />
    <Authorization url="https://www.google.com/accounts/OAuthAuthorizeToken?
                        oauth_callback=http://oauth.gmodules.com/gadgets/oauthcallback" />
  </Service>
</OAuth>
...
</ModulePrefs>

בקטע הזה צריך לשנות רק את הפרמטרים הבאים של השאילתות:

scope: פרמטר נדרש בכתובת ה-URL של הבקשה. הגאדג'ט שלך יכול לגשת לנתונים מתוך scope(ים) שבהם נעשה שימוש בפרמטר זה. בדוגמה הזו, הגאדג'ט יכול לגשת לנתונים של Blogger ושל יומן Google. גאדג'ט יכול לבקש נתונים עבור היקף או היקף אחד, כפי שניתן לעשות עם הדוגמה.
oauth_callback: פרמטר אופציונלי בכתובת ה-URL להרשאה. דף אישור ה-OAuth מפנה לכתובת ה-URL הזו לאחר שהמשתמש אישר גישה לנתונים. עליך להגדיר את הפרמטר הזה כ-http://oauth.gmodules.com/gadgets/oauthcallback כדי לספק את חוויית המשתמש הטובה ביותר כשמשתמשים מתקינים את הגאדג'ט שלך. דף זה מספק קטע JavaScript שסוגר את החלון הקופץ באופן אוטומטי. לחלופין, אפשר להגדיר את הפרמטר כך שיפנה לדף "מאושר" משלכם. לחלופין, אפשר פשוט להשאיר את הפרמטר ריק.

גישה לעדכון מאומת של Google Data API

לאחר שהגאדג'ט שלך אימת את המשתמש, הגישה לממשק API של Google Data API פשוטה באמצעות ספריית לקוח ממשקי ה-JavaScript של Google Data APIs. למידע על השימוש בספרייה בשרת ה-proxy של OAuth, ניתן לעיין במאמר שימוש בספריית הלקוח של JavaScript.

מידע נוסף על גאדג'טים

למידע מלא על יצירת גאדג'טים של ממשק API של נתונים של Google, כולל פרטים על שרת ה-proxy של OAuth, מאמר המסביר כיצד להתחיל בעבודה ומפרט gadgets.*, עיין במקורות נוספים אלה:

שימוש בספריית הלקוח של JavaScript
יצירת גאדג'ט של Google Data APIs (מאמר)
כתיבת גאדג'טים של OAuth (תיעוד מלא של הגאדג'ט)
תיעוד של הגאדג'טים API

חזרה למעלה