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

איך לטפל בהרשאות מפורטות

סקירה כללית

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

מהי הרשאה מפורטת?

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

כשנשלחת בקשה לכמה היקף הרשאות שלא מיועד לכניסה

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

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

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

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

מספר היקפי הכניסה	מספר ההיקפים שאינם קשורים לכניסה לחשבון	מסך הסכמה מפורט להרשאות
1-3	0	לא רלוונטי
1-3	1+	רלוונטי
0	1	לא רלוונטי
0	2+	רלוונטי

לבדוק אם האפליקציות שלכם מושפעות

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

איך לקבוע אם האפליקציה שלכם משתמשת בכמה היקפים

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

בדיקת קוד האפליקציה

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

Google Identity Services

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

const client = google.accounts.oauth2.initTokenClient({
  client_id: 'YOUR_CLIENT_ID',
  scope: 'https://www.googleapis.com/auth/calendar.readonly \
  https://www.googleapis.com/auth/contacts.readonly',
  callback: (response) => {
    ...
  },
});

Python

קטע הקוד הבא משתמש במודול google-auth-oauthlib.flow כדי ליצור את בקשת ההרשאה; הפרמטר scope כולל היקפים שלא מיועדים לכניסות לחשבון. מסך ההסכמה המפורט להרשאות יוצג כשנתוני האינטרנט אפליקציה מבקשת הרשאה ממשתמשים.

import google.oauth2.credentials
import google_auth_oauthlib.flow

# Use the client_secret.json file to identify the application requesting
# authorization. The client ID (from that file) and access scopes are required.
flow = google_auth_oauthlib.flow.Flow.from_client_secrets_file(
    'client_secret.json',
    scopes=['https://www.googleapis.com/auth/calendar.readonly',
                    'https://www.googleapis.com/auth/contacts.readonly'])

Node.js

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

const {google} = require('googleapis');

/**
  * To use OAuth2 authentication, we need access to a CLIENT_ID, CLIENT_SECRET, AND REDIRECT_URI
  * from the client_secret.json file. To get these credentials for your application, visit
  * https://console.cloud.google.com/apis/credentials.
  */
const oauth2Client = new google.auth.OAuth2(
  YOUR_CLIENT_ID,
  YOUR_CLIENT_SECRET,
  YOUR_REDIRECT_URL
);

// Access scopes for read-only Calendar and Contacts.
const scopes = [
  'https://www.googleapis.com/auth/calendar.readonly',
  'https://www.googleapis.com/auth/contacts.readonly']
];

// Generate a url that asks permissions
const authorizationUrl = oauth2Client.generateAuthUrl({
  // 'online' (default) or 'offline' (gets refresh_token)
  access_type: 'offline',
  /** Pass in the scopes array defined above.
    * Alternatively, if only one scope is needed, you can pass a scope URL as a string */
  scope: scopes,
  // Enable incremental authorization. Recommended as best practices.
  include_granted_scopes: true
});

בדיקה של שיחת רשת יוצאת

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

אפליקציית אינטרנט - בדיקה של הפעילות ברשת ב-Chrome
Android – לבדוק את התנועה ברשת באמצעות 'בודק הרשת'
אפליקציות Chrome
- עוברים אל תוספים ל-Chrome דף
- מסמנים את התיבה מצב פיתוח בפינה השמאלית העליונה הפינה בדף התוסף
- בחירת התוסף שאחריו רוצים לעקוב
- לוחצים על הקישור דף הרקע הקטע בדיקת תצוגות בדף התוסף
- יופיע חלון קופץ של כלים למפתחים, שבו תוכלו לעקוב אחרי תעבורת הנתונים ברשת בכרטיסייה Network.
iOS – ניתוח תנועת HTTP באמצעות Instruments
Universal Windows Platform (UWP) – בדיקת התנועה ברשת ב-Visual Studio
אפליקציות למחשב - שימוש בכלי לצילום רשת שזמינות למערכת ההפעלה שעבורה פותחה האפליקציה

בזמן הבדיקה של שיחות הרשת, כדאי לחפש בקשות שנשלחו ל-OAuth של Google Author endpoints ובוחנים את הפרמטר scope.

הערכים האלה גורמים להצגת מסך ההסכמה להרשאות מפורטות.

הפרמטר scope מכיל היקפים של כניסה והיקפים לא כניסה.

הבקשה הבאה לדוגמה מכילה את כל שלושת היקפי ההרשאות של הכניסה והיקף אחד שאינו 'כניסה' כדי להציג את המטא-נתונים של קובצי Google Drive של המשתמש:

https://accounts.google.com/o/oauth2/v2/auth?
access_type=offline&
scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile%20openid%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.metadata.readonly&
include_granted_scopes=true&
response_type=code&
redirect_uri=YOUR_REDIRECT_URL&
client_id=YOUR_CLIENT_ID

הפרמטר scope מכיל יותר מהיקף אחד שאינו 'כניסה'.

הבקשה הבאה לדוגמה מכילה שני היקפי הרשאות שלא 'כניסה לחשבון' כדי להציג את קובץ Google Drive של המשתמש מטא-נתונים ומנהלים קבצים ספציפיים ב-Google Drive:

https://accounts.google.com/o/oauth2/v2/auth?
access_type=offline&
scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.metadata.readonly%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.file&
include_granted_scopes=true&
response_type=code&
redirect_uri=YOUR_REDIRECT_URL&
client_id=YOUR_CLIENT_ID

שיטות מומלצות לטיפול בהרשאות מפורטות

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

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

עדכון האפליקציה לטיפול בהרשאות מפורטות

אפליקציות ל-Android

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

אם משתמשים auth.api.signin SDK מ-Play Services כדי ליצור אינטראקציה עם OAuth 2.0 של Google, אפשר להשתמש requestPermissions כדי לבקש את הקבוצה הקטנה ביותר של היקפי ההרשאות שנדרשת, את הרצף hasPermissions כדי לבדוק את היקף ההרשאות שהמשתמש העניק כאשר בקשת הרשאות מפורטות.

אפליקציות של תוספים ל-Chrome

צריך להשתמש Chrome Identity API לעבודה עם OAuth 2.0 של Google על סמך שיטות מומלצות.

הדוגמה הבאה מראה איך לטפל כראוי בהרשאות מפורטות.

manifest.json

בקובץ המניפסט לדוגמה יש הצהרה על שני היקפי הרשאות ללא כניסה לתוסף ל-Chrome. תרגום מכונה.

{
  "name": "Example Chrome extension application",
  ...
  "permissions": [
      "identity"
    ],
  "oauth2" : {
      "client_id": "YOUR_CLIENT_ID",
      "scopes":["https://www.googleapis.com/auth/calendar.readonly",
                "https://www.googleapis.com/auth/contacts.readonly"]
  }
}

גישה שגויה

הכול או כלום

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

oauth.js

...
document.querySelector('button').addEventListener('click', function () {
  chrome.identity.getAuthToken({ interactive: true },
      function (token) {
          if (token === undefined) {
            // User didn't authorize both scopes.
            // Updating the UX and application accordingly
            ...
          } else {
            // User authorized both or one of the scopes.
            // It neglects to check which scopes users granted and assumes users granted all scopes.

            // Calling the APIs, etc.
            ...
          }
      });
});

גישה נכונה

ההיקפים הקטנים ביותר

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

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

בדוגמה הזו, ההנחה היא ששני ההיקפים שמוצהרים בקובץ manifest.json הם קבוצת ההיקפים הקטנה ביותר שנדרשת. קובץ oauth.js משתמש ב-Chrome Identity API כדי להתחיל את תהליך ההרשאה עם Google. מומלץ להביע הסכמה להפעלת הרשאות מפורטות כדי שלמשתמשים תהיה שליטה רבה יותר במתן ההרשאות לאפליקציה. האפליקציה צריכה לטפל כראוי בתגובה מהמשתמשים על ידי בדיקה של אילו היקפים המשתמשים מאשרים.

oauth.js

...
document.querySelector('button').addEventListener('click', function () {
  chrome.identity.getAuthToken({ interactive: true, enableGranularPermissions: true },
      function (token, grantedScopes) {
          if (token === undefined) {
            // User didn't authorize any scope.
            // Updating the UX and application accordingly
            ...
          } else {
            // User authorized the request. Now, check which scopes were granted.
            if (grantedScopes.includes('https://www.googleapis.com/auth/calendar.readonly'))
            {
              // User authorized Calendar read permission.
              // Calling the APIs, etc.
              ...
            }
            else
            {
              // User didn't authorize Calendar read permission.
              // Update UX and application accordingly
              ...
            }

            if (grantedScopes.includes('https://www.googleapis.com/auth/contacts.readonly'))
            {
              // User authorized Contacts read permission.
              // Calling the APIs, etc.
              ...
            }
            else
            {
              // User didn't authorize Contacts read permission.
              // Update UX and application accordingly
              ...
            }
          }
      });
});

אפליקציות ל-iOS , iPadOS ו-macOS

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

אפליקציות אינטרנט

גישה בצד השרת (אופליין)

מצב הגישה בצד השרת (אופליין) מחייב אתכם לבצע את הפעולות הבאות:

מפעילים שרת ומגדירים נקודת קצה שגלויה לכולם כדי לקבל את קוד ההרשאה.
מגדירים את ה-URI להפניה אוטומטית של נקודת הקצה הציבורית שלכם Credentials page במסוף Google Cloud.

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

גישה שגויה

הכול או כלום

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

main.js

...
const oauth2Client = new google.auth.OAuth2(
  YOUR_CLIENT_ID,
  YOUR_CLIENT_SECRET,
  YOUR_REDIRECT_URL
);

// Access scopes for two non-Sign-In scopes - Google Calendar and Contacts
const scopes = [
  'https://www.googleapis.com/auth/contacts.readonly',
  'https://www.googleapis.com/auth/calendar.readonly'
];

// Generate a url that asks permissions for the Google Calendar and Contacts scopes
const authorizationUrl = oauth2Client.generateAuthUrl({
  // 'online' (default) or 'offline' (gets refresh_token)
  access_type: 'offline',
  // Pass in the scopes array defined above
  scope: scopes,
  // Enable incremental authorization. Recommended as best practices.
  include_granted_scopes: true
});

async function main() {
  const server = http.createServer(async function (req, res) {
    // Example on redirecting user to Google OAuth 2.0 server.
    if (req.url == '/') {
      res.writeHead(301, { "Location": authorizationUrl });
    }
    // Receive the callback from Google OAuth 2.0 server.
    if (req.url.startsWith('/oauth2callback')) {
      // Handle the Google OAuth 2.0 server response
      let q = url.parse(req.url, true).query;

      if (q.error) {
        // User didn't authorize both scopes.
        // Updating the UX and application accordingly
        ...
      } else {
        // User authorized both or one of the scopes.
        // It neglects to check which scopes users granted and assumes users granted all scopes.

        // Get access and refresh tokens (if access_type is offline)
        let { tokens } = await oauth2Client.getToken(q.code);
        // Calling the APIs, etc.
        ...
      }
    }
    res.end();
  }).listen(80);
}

גישה נכונה

ההיקף הקטן ביותר

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

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

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

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

main.js

...
const oauth2Client = new google.auth.OAuth2(
  YOUR_CLIENT_ID,
  YOUR_CLIENT_SECRET,
  YOUR_REDIRECT_URL
);

// Access scopes for two non-Sign-In scopes - Google Calendar and Contacts
const scopes = [
  'https://www.googleapis.com/auth/contacts.readonly',
  'https://www.googleapis.com/auth/calendar.readonly'
];

// Generate a url that asks permissions for the Google Calendar and Contacts scopes
const authorizationUrl = oauth2Client.generateAuthUrl({
  // 'online' (default) or 'offline' (gets refresh_token)
  access_type: 'offline',
  // Pass in the scopes array defined above
  scope: scopes,
  // Enable incremental authorization. Recommended as best practices.
  include_granted_scopes: true,
  // Set to true to enable more granular permissions for Google OAuth 2.0 client IDs created before 2019.
  // No effect for newer Google OAuth 2.0 client IDs, since more granular permissions is always enabled for them.
  enable_granular_consent: true
});

async function main() {
  const server = http.createServer(async function (req, res) {
    // Redirect users to Google OAuth 2.0 server.
    if (req.url == '/') {
      res.writeHead(301, { "Location": authorizationUrl });
    }
    // Receive the callback from Google OAuth 2.0 server.
    if (req.url.startsWith('/oauth2callback')) {
      // Handle the Google OAuth 2.0 server response
      let q = url.parse(req.url, true).query;

      if (q.error) {
        // User didn't authorize both scopes.
        // Updating the UX and application accordingly
        ...
      } else {
        // Get access and refresh tokens (if access_type is offline)
        let { tokens } = await oauth2Client.getToken(q.code);
        oauth2Client.setCredentials(tokens);

        // User authorized the request. Now, check which scopes were granted.
        if (tokens.scope.includes('https://www.googleapis.com/auth/calendar.readonly'))
        {
          // User authorized Calendar read permission.
          // Calling the APIs, etc.
          ...
        }
        else
        {
          // User didn't authorize Calendar read permission.
          // Calling the APIs, etc.
          ...
        }

        // Check which scopes user granted the permission to application
        if (tokens.scope.includes('https://www.googleapis.com/auth/contacts.readonly'))
        {
          // User authorized Contacts read permission.
          // Calling the APIs, etc.
          ...
        }
        else
        {
          // User didn't authorize Contacts read permission.
          // Update UX and application accordingly
          ...
        }
      }
    }
    res.end();
  }).listen(80);
}

כדאי לקרוא את מדריך לאפליקציות אינטרנט בצד השרת שמסביר איך לגשת לממשקי ה-API של Google מאפליקציות מבוססות-שרת.

גישה בצד הלקוח בלבד

לאפליקציות שמשתמשות ב-Google Identity Services ספריית ה-JavaScript ליצירת אינטראקציה עם Google OAuth 2.0, צריך לבדוק מסמכי תיעוד בנושא טיפול בהרשאות מפורטות.
עבור אפליקציות שמבצעות קריאות ישירות באמצעות JavaScript להרשאות OAuth 2.0 של Google צריך לבדוק מסמכי תיעוד בנושא טיפול בהרשאות מפורטות.

בדיקת האפליקציה המעודכנת בטיפול בהרשאות מפורטות

Outline על כל המקרים שבהם המשתמשים יכולים להגיב לבקשות הרשאה, ההתנהגות הצפויה של האפליקציה. לדוגמה, אם המשתמש מאשר רק שני חשבונות מתוך שלושת ההיקפים הנדרשים, האפליקציה צריכה להתנהג בהתאם.
בודקים את האפליקציה באמצעות הרשאה מפורטת מופעלת. יש שתי דרכים להפעיל את הרשאות מפורטות:
1. צריך לבדוק את מסכי ההסכמה של OAuth 2.0 באפליקציה כדי לראות אם הרשאות מפורטות כבר הופעלו תרגום מכונה. אפשר גם ליצור מזהה לקוח חדש של Google OAuth 2.0 באינטרנט, ב-Android או ב-iOS דרך מסוף Google Cloud למטרות בדיקה, כי תמיד תהיה הרשאה מפורטת מופעלת עבורם.
2. הגדרת הפרמטר enable_granular_consent אל true כשקוראים ל-OAuth של Google נקודות קצה (endpoints) של הרשאה. בחלק מערכות ה-SDK יש תמיכה מפורשת בנושא הזה הפרמטר. לגבי אחרים, כדאי לעיין במסמכי התיעוד כדי לראות איך אפשר להוסיף את הפרמטר הזה. את הערך שלו באופן ידני. אם ההטמעה שלכם לא תומכת בהוספת הפרמטר, אתם יכולים ליצור דף אינטרנט חדש מזהה לקוח OAuth 2.0 של Google או Android או iOS דרך מסוף Google Cloud למטרות בדיקה למטרות בלבד, כפי שצוין בנקודה הקודמת.
  חשוב: כש-Google מפעילה הרשאות מפורטות לאפליקציה, הפרמטר enable_granular_consent לא ישפיע יותר.
כשבודקים את האפליקציה המעודכנת, צריך להשתמש בחשבון Google אישי (@gmail.com) במקום חשבון Workspace. הסיבה לכך היא שאפליקציות Workspace Enterprise עם האצלת סמכויות ברמת הדומיין או מסומנת בתור מהימן לא מושפעים משינויים בהרשאות המפורטות בשלב הזה. לכן, ביצוע בדיקות באמצעות Workspace יכול להיות שבחשבון הארגון שלכם לא יוצג מסך ההסכמה המפורט החדש כמו שצריך.

איך לטפל בהרשאות מפורטות

סקירה כללית

מהי הרשאה מפורטת?

כשנשלחת בקשה לכמה היקף הרשאות שלא מיועד לכניסה

היקפים של כניסה לחשבון והיקפים שלא קשורים לכניסה לחשבון

יותר מטווח אחד שלא קשור לכניסה

לבדוק אם האפליקציות שלכם מושפעות

איך לקבוע אם האפליקציה שלכם משתמשת בכמה היקפים

בדיקת קוד האפליקציה

Google Identity Services

Python

Node.js

בדיקה של שיחת רשת יוצאת

שיטות מומלצות לטיפול בהרשאות מפורטות

עדכון האפליקציה לטיפול בהרשאות מפורטות

אפליקציות ל-Android

אפליקציות של תוספים ל-Chrome

גישה שגויה

הכול או כלום

גישה נכונה

ההיקפים הקטנים ביותר

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

אפליקציות ל-iOS , iPadOS ו-macOS

אפליקציות אינטרנט

גישה בצד השרת (אופליין)

גישה שגויה

הכול או כלום

גישה נכונה

ההיקף הקטן ביותר

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

גישה בצד הלקוח בלבד

בדיקת האפליקציה המעודכנת בטיפול בהרשאות מפורטות