אימות משתמשים באמצעות PHP

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

מטרות

  • לדרוש מהמשתמשים באפליקציית App Engine לאמת את עצמם באמצעות IAP.

  • לגשת לזהויות של המשתמשים באפליקציה כדי להציג את כתובת האימייל המאומתת של המשתמש הנוכחי.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

כדי ליצור הערכת עלויות בהתאם לשימוש החזוי, אתם יכולים להשתמש במחשבון התמחור.

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

לפני שמתחילים

  1. נכנסים לחשבון Google Cloud . אנחנו ממליצים למשתמשים חדשים ב- Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.
  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Install the Google Cloud CLI.

  4. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  5. To initialize the gcloud CLI, run the following command:

    gcloud init
  6. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  7. Install the Google Cloud CLI.

  8. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  9. To initialize the gcloud CLI, run the following command:

    gcloud init

רקע

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

אפליקציית Hello user-email-address

האפליקציה במדריך הזה היא אפליקציית App Engine מינימלית מסוג Hello world, עם תכונה אחת לא אופיינית: במקום Hello world, היא מציגה את הטקסט Hello user-email-address, כאשר user-email-address היא כתובת האימייל של המשתמש המאומת.

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

  • ‫X-Goog-Authenticated-User-Email: כתובת האימייל של המשתמש מזהה אותו. אם אפשר, אל תאחסנו מידע אישי באפליקציה. האפליקציה הזו לא שומרת נתונים, היא רק מחזירה אותם למשתמש.

  • X-Goog-Authenticated-User-Id: מזהה המשתמש הזה שמוקצה על ידי Google לא מציג מידע על המשתמש, אבל הוא מאפשר לאפליקציה לדעת שמשתמש מחובר הוא אותו משתמש שנראה בעבר.

  • ‫X-Goog-Iap-Jwt-Assertion: אפשר להגדיר Google Cloud אפליקציות לקבל בקשות אינטרנט מאפליקציות אחרות בענן, בלי לעבור דרך IAP, בנוסף לבקשות אינטרנט מהאינטרנט. אם אפליקציה מוגדרת כך, יכול להיות שבבקשות כאלה יהיו כותרות מזויפות. במקום להשתמש באחד מהכותרות של הטקסט הפשוט שצוינו קודם, אפשר להשתמש בכותרת הזו שחתמה באופן קריפטוגרפי ולאמת אותה כדי לבדוק שהמידע סופק על ידי Google. כתובת האימייל של המשתמש ומזהה משתמש קבוע זמינים כחלק מהכותרת החתומה הזו.

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

‫
$userId = getallheaders()['X-Goog-Authenticated-User-Id'] ?? null;

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

יצירת קוד המקור

  1. משתמשים בכלי לעריכת טקסט כדי ליצור קובץ בשם index.php ומדביקים בו את הקוד הבא:

    require_once __DIR__ . '/vendor/autoload.php';
    
    /**
     * Checks that the JWT assertion is valid (properly signed, for the
     * correct audience) and if so, returns strings for the requesting user's
     * email and a persistent user ID. If not valid, returns null for each field.
     *
     * @param string $idToken The JWT string to assert.
     * @param string $audience The audience of the JWT.
     *
     * @return string[] array containing [$email, $id]
     * @throws Exception on failed validation
     */
    function validate_assertion(string $idToken, string $audience) : array
    {
        $auth = new Google\Auth\AccessToken();
        $info = $auth->verify($idToken, [
          'certsLocation' => Google\Auth\AccessToken::IAP_CERT_URL,
          'throwException' => true,
        ]);
    
        if ($audience != $info['aud'] ?? '') {
            throw new Exception(sprintf(
                'Audience %s did not match expected %s', $info['aud'], $audience
            ));
        }
    
        return [$info['email'], $info['sub']];
    }
    
    /**
     * This is an example of a front controller for a flat file PHP site. Using a
     * static list provides security against URL injection by default.
     */
    switch (@parse_url($_SERVER['REQUEST_URI'])['path']) {
        case '/':
            if (!Google\Auth\Credentials\GCECredentials::onGce()) {
                throw new Exception('You must deploy to appengine to run this sample');
            }
            $metadata = new Google\Cloud\Core\Compute\Metadata();
            $audience = sprintf(
                '/projects/%s/apps/%s',
                $metadata->getNumericProjectId(),
                $metadata->getProjectId()
            );
            $idToken = getallheaders()['X-Goog-Iap-Jwt-Assertion'] ?? '';
            try {
                list($email, $id) = validate_assertion($idToken, $audience);
                printf("<h1>Hello %s</h1>", $email);
            } catch (Exception $e) {
                printf('Failed to validate assertion: %s', $e->getMessage());
            }
            break;
        case '': break; // Nothing to do, we're running our tests
        default:
            http_response_code(404);
            exit('Not Found');
    }

    הסבר מפורט על הקובץ index.php מופיע בקטע הסבר על הקוד בהמשך המדריך הזה.

  2. יוצרים קובץ נוסף בשם composer.json ומדביקים בו את התוכן הבא:

    {
      "require": {
        "php": ">=7.1",
        "google/auth": "^1.9",
        "google/cloud-core": "^1.32",
        "kelvinmo/simplejwt": "^0.4.0"
      }
    }
    

    בקובץ composer.json מפורטות כל ספריות ה-PHP שהאפליקציה צריכה לטעון ב-App Engine:

    • firebase/php-jwt מספקת את פונקציית הבדיקה והפענוח של JWT.

    • ‫guzzle/http הוא לקוח HTTP לאחזור נתונים מאתרי אינטרנט.

  3. יוצרים קובץ בשם app.yaml ומכניסים לתוכו את הטקסט הבא:

    runtime: php73
    

    קובץ app.yaml מציין ל-App Engine איזו סביבת שפה נדרשת לקוד.

הסבר על הקוד

בקטע הזה מוסבר איך הקוד ב-index.php פועל. אם אתם רק רוצים להפעיל את האפליקציה, אתם יכולים לדלג אל הקטע פריסת האפליקציה.

הקוד הבא נמצא בקובץ index.php. כשבקשת HTTP GET לדף הבית מתקבלת באפליקציה, מופעלת ההוראה switch case עבור /:

/**
 * This is an example of a front controller for a flat file PHP site. Using a
 * static list provides security against URL injection by default.
 */
switch (@parse_url($_SERVER['REQUEST_URI'])['path']) {
    case '/':
        if (!Google\Auth\Credentials\GCECredentials::onGce()) {
            throw new Exception('You must deploy to appengine to run this sample');
        }
        $metadata = new Google\Cloud\Core\Compute\Metadata();
        $audience = sprintf(
            '/projects/%s/apps/%s',
            $metadata->getNumericProjectId(),
            $metadata->getProjectId()
        );
        $idToken = getallheaders()['X-Goog-Iap-Jwt-Assertion'] ?? '';
        try {
            list($email, $id) = validate_assertion($idToken, $audience);
            printf("<h1>Hello %s</h1>", $email);
        } catch (Exception $e) {
            printf('Failed to validate assertion: %s', $e->getMessage());
        }
        break;
    case '': break; // Nothing to do, we're running our tests
    default:
        http_response_code(404);
        exit('Not Found');
}

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

/**
 * Checks that the JWT assertion is valid (properly signed, for the
 * correct audience) and if so, returns strings for the requesting user's
 * email and a persistent user ID. If not valid, returns null for each field.
 *
 * @param string $idToken The JWT string to assert.
 * @param string $audience The audience of the JWT.
 *
 * @return string[] array containing [$email, $id]
 * @throws Exception on failed validation
 */
function validate_assertion(string $idToken, string $audience) : array
{
    $auth = new Google\Auth\AccessToken();
    $info = $auth->verify($idToken, [
      'certsLocation' => Google\Auth\AccessToken::IAP_CERT_URL,
      'throwException' => true,
    ]);

    if ($audience != $info['aud'] ?? '') {
        throw new Exception(sprintf(
            'Audience %s did not match expected %s', $info['aud'], $audience
        ));
    }

    return [$info['email'], $info['sub']];
}

הפונקציה validate_assertion משתמשת בספרייה google/auth כדי לוודא שההצהרה חתומה בצורה תקינה, וכדי לחלץ את פרטי המטען הייעודי (payload) מההצהרה. אם אי אפשר לפענח את הטענה, הפונקציה יוצרת חריגה. אם הפונקציה מצליחה, היא מחזירה את כתובת האימייל של המשתמש המאומת ומזהה ייחודי קבוע של המשתמש.

כדי לאמת טענת נכוֹנוּת (assertion) של JWT, צריך לדעת מהם אישורי המפתח הציבורי של הישות שחתמה על הטענה (Google במקרה הזה), ומי הקהל שהטענה מיועדת לו. באפליקציית App Engine, הקהל הוא מחרוזת עם פרטי הזיהוי של הפרויקט Google Cloud . הפונקציה הזו מקבלת את האישורים האלה ואת מחרוזת הקהל מהפונקציות שקדמו לה.

$metadata = new Google\Cloud\Core\Compute\Metadata();
$audience = sprintf(
    '/projects/%s/apps/%s',
    $metadata->getNumericProjectId(),
    $metadata->getProjectId()
);

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

שירות המטא-נתונים של App Engine (ושירותי מטא-נתונים דומים לשירותי מחשוב אחרים שלGoogle Cloud ) נראה כמו אתר אינטרנט, והשאילתות שמופנות אליו הן שאילתות אינטרנט רגילות. עם זאת, זה לא אתר חיצוני, אלא תכונה פנימית שמחזירה מידע מבוקש על האפליקציה שפועלת, ולכן בטוח להשתמש בבקשות http במקום בבקשות https. הוא משמש לקבלת המזהים הנוכחיים Google Cloud שנדרשים להגדרת הקהל המיועד של הצהרת ה-JWT.

פריסת האפליקציה

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

  1. בחלון הטרמינל, עוברים לתיקייה שמכילה את הקובץ app.yaml ומפעילים את האפליקציה ב-App Engine:

    gcloud app deploy
    
  2. כשמופיעה בקשה, בוחרים אזור קרוב.

  3. כשמוצגת השאלה אם רוצים להמשיך בפעולת הפריסה, מזינים Y.

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

  4. צפייה באפליקציה:

    gcloud app browse
    

    בפלט, מעתיקים את web-site-url, כתובת האינטרנט של האפליקציה.

  5. בחלון הדפדפן, מדביקים את web-site-url כדי לפתוח את האפליקציה.

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

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

עכשיו, כשיש מופע של App Engine, אפשר להגן עליו באמצעות IAP:

  1. נכנסים לדף שרת proxy לאימות זהויות (IAP) במסוף Google Cloud .

    כניסה לדף "שרת proxy לאימות זהויות (IAP)"

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

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

  3. בכרטיסייה OAuth Consent Screen בדף Credentials, ממלאים את השדות הבאים:

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

    • בשדה Application name, מזינים את הערך IAP Example.

    • בשדה כתובת אימייל לתמיכה, מזינים את כתובת האימייל שלכם.

    • בשדה Authorized domain, מזינים את החלק של שם המארח בכתובת ה-URL של האפליקציה, לדוגמה iap-example-999999.uc.r.appspot.com. מקישים על המקש Enter אחרי שמזינים את שם המארח בשדה.

    • בשדה Application homepage link (קישור לדף הבית של האפליקציה), מזינים את כתובת ה-URL של האפליקציה, לדוגמה, https://iap-example-999999.uc.r.appspot.com/.

    • בשדה Application privacy policy line (שורת מדיניות הפרטיות של האפליקציה), משתמשים באותה כתובת URL כמו הקישור לדף הבית לצורכי בדיקה.

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

  5. נכנסים לדף שרת proxy לאימות זהויות (IAP) במסוף Google Cloud .

    כניסה לדף "שרת proxy לאימות זהויות (IAP)"

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

  7. בעמודה IAP, לוחצים כדי להפעיל את הרכישה מתוך האפליקציה.

  8. בדפדפן, עוברים אל web-site-url שוב.

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

הוספת משתמשים מורשים לאפליקציה

  1. נכנסים לדף שרת proxy לאימות זהויות (IAP) במסוף Google Cloud .

    מעבר לדף של שרת proxy לאימות זהויות (IAP)

  2. מסמנים את התיבה של אפליקציית App Engine ולוחצים על Add Principal.

  3. מזינים allAuthenticatedUsers ובוחרים את התפקיד Cloud IAP/IAP-Secured Web App User.

  4. לוחצים על Save.

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

  • כל כתובת אימייל ב-Gmail או ב-Google Workspace

  • כתובת אימייל של קבוצה ב-Google

  • שם דומיין של Google Workspace

גישה לאפליקציה

  1. בדפדפן, עוברים אל web-site-url.

  2. כדי לרענן את הדף, לוחצים על רענון .

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

    בדף מופיעה ההודעה 'שלום user-email-address' עם כתובת האימייל שלכם.

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

מושגי אימות

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

אפשרות יתרונות חסרונות
אימות אפליקציות
  • האפליקציה יכולה לפעול בכל פלטפורמה, עם או בלי חיבור לאינטרנט
  • המשתמשים לא צריכים להשתמש בשירות אחר כדי לנהל את האימות
  • האפליקציה צריכה לנהל את פרטי הכניסה של המשתמשים בצורה מאובטחת, ולהגן עליהם מפני חשיפה.
  • האפליקציה חייבת לשמור את נתוני הסשן של משתמשים מחוברים
  • האפליקציה צריכה לספק למשתמשים אפשרות להירשם, לשנות את הסיסמה ולשחזר אותה
OAuth2
  • האפליקציה יכולה לפעול בכל פלטפורמה שמחוברת לאינטרנט, כולל תחנת עבודה של מפתח
  • האפליקציה לא צריכה פונקציות של רישום משתמשים, שינוי סיסמאות או שחזור סיסמאות.
  • הסיכון לחשיפת מידע על המשתמשים מועבר לשירות אחר
  • אמצעי אבטחה חדשים לכניסה לחשבון שמטופלים מחוץ לאפליקציה
  • המשתמשים צריכים להירשם לשירות הזהויות
  • האפליקציה צריכה לשמור את נתוני הסשן של משתמשים מחוברים
IAP
  • לא צריך להוסיף קוד לאפליקציה כדי לנהל משתמשים, אימות או מצב סשן
  • באפליקציה אין פרטי כניסה של משתמשים שעלולים להיפרץ
  • האפליקציה יכולה לפעול רק בפלטפורמות שהשירות תומך בהן. באופן ספציפי, שירותים מסוימים של Google Cloud שתומכים ב-IAP, כמו App Engine.

אימות שמנוהל על ידי האפליקציה

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

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

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

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

אימות חיצוני באמצעות OAuth2

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

התרשים הבא ממחיש את האימות החיצוני באמצעות שיטת OAuth2.

תהליך OAuth2

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

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

שרת proxy לאימות זהויות (IAP)

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

בתרשים הבא מוצג אופן הטיפול בבקשה.

תהליך הרכישה מתוך האפליקציה

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

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

הסרת המשאבים

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

  1. נכנסים לדף Manage resources במסוף Google Cloud .

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

המאמרים הבאים