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

סקירה כללית

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

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

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

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

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

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

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

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

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

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

באפליקציות שמבקשות רק היקפי כניסה (email, profile ו-openid), מסך ההסכמה להרשאות #inspect-your-Application-codegranular. המשתמשים מאשרים או דוחים את כל בקשת הכניסה. במילים אחרות, אם אפליקציות מבקשות רק כניסה להיקפים (אחד, שניים או כל השלושה), מסך ההסכמה המפורט של ההרשאה לא רלוונטי.

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

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

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

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

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

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

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

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

Google Identity Services

קטע הקוד של ספריית ה-JavaScript של Google Identity Services מפעיל את 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
});

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

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

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

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

  • הפרמטר 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קטע הקוד הבא מציג דוגמה של 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);
}

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

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

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

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

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