קישור חשבונות באמצעות 'כניסה באמצעות חשבון Google' המבוססת על OAuth

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

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

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

כדי לקשר חשבון מסוג 'שיפור יעיל', פועלים לפי השלבים הכלליים הבאים:

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

תמיכה ביצירת חשבון באמצעות הקול

כשמאפשרים יצירה של חשבון משתמש באמצעות הקול, Assistant שואלת את המשתמשים אם לבצע את הפעולות הבאות:

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

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

אי אפשר ליצור חשבון באמצעות הקול

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

חסימת היצירה מומלצת אם:

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

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

הטמעה של קישור "מהיר" לכניסה באמצעות חשבון Google שמבוסס על OAuth

החשבונות מקושרים לתהליכי OAuth 2.0 המקובלים בתחום. פעולות ב-Google תומכות בתהליכי קוד הרשאה וקוד הרשאה.

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

בתהליך הקוד של ההרשאה, נדרשות שתי נקודות קצה:

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

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

הגדרת הפרויקט

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

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

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

  6. בקטע פרטי הלקוח, מבצעים את הפעולות הבאות:

    • כדי לזהות בקשות שמגיעות מ-Google, מקצים ערך ל-Client-ID שהונפק על ידי Actions to Google.
    • עליך להזין את כתובות ה-URL של נקודות הקצה Authorization ו-Token Exchange.

  7. לוחצים על שמירה.

הטמעה של שרת OAuth

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

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

סשן זרימה מרומז של OAuth 2.0 טיפוסי ש-Google יזמה כולל את התהליך הבא:

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

טיפול בבקשות הרשאה

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

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

לדוגמה, אם נקודת הקצה של ההרשאה זמינה ב-https://myservice.example.com/auth, בקשה עשויה להיראות כך:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&response_type=token

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

  1. מאמתים את הערכים client_id ו-redirect_uri כדי למנוע מתן גישה לאפליקציות לקוח לא מכוונות או שהוגדרו באופן שגוי:

    • מוודאים ש-client_id תואם למזהה הלקוח שהקציתם ל-Google.
    • מוודאים שכתובת ה-URL שצוינה בפרמטר redirect_uri מופיעה בצורה הבאה:
      https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
      YOUR_PROJECT_ID הוא המזהה שנמצא בדף Project settings ב-Actions Console.

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

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

  4. שולחים תגובת HTTP שמפנה את דפדפן המשתמש לכתובת ה-URL שצוינה בפרמטר redirect_uri. יש לכלול את כל הפרמטרים הבאים בקטע של כתובת ה-URL:

    • access_token: אסימון הגישה שיצרת עכשיו
    • token_type: המחרוזת bearer
    • state: ערך המצב של הבקשה המקורית ללא שינוי בהמשך מוצגת דוגמה לכתובת ה-URL שהתקבלה: 
      https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING

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

מה עושים בקישור האוטומטי?

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

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

הבקשה כוללת את הטופס הבא:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&intent=get&assertion=JWT&consent_code=CONSENT_CODE&scope=SCOPES

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

הפרמטרים של נקודת הקצה של האסימון
grant_type סוג האסימון שמועבר. בבקשות האלה, הפרמטר הזה מכיל את הערך urn:ietf:params:oauth:grant-type:jwt-bearer.
intent לבקשות האלה, הערך של הפרמטר הוא 'get'.
assertion אסימון Web Token (JWT) שמספק טענת נכוֹנוּת (assertion) חתומה של זהות המשתמש ב-Google. ה-JWT מכיל מידע שכולל את מספר חשבון Google, השם וכתובת האימייל של המשתמש.
consent_code אופציונלי: כשמוצג קוד חד-פעמי, שמציין שהמשתמש נתן את הסכמתו לפעולה שלכם לגשת להיקפי ההרשאות שצוינו.
scope אופציונלי: היקפים שהגדרתם ל-Google לבקש ממשתמשים.

כשנקודת הקצה של המרת האסימונים מקבלת את בקשת הקישור, היא צריכה לבצע את הדברים הבאים:

אימות ופענוח של טענת ה-JWT

אפשר לאמת ולפענח את טענת ה-JWT באמצעות ספריית פענוח JWT בשפה שלכם. משתמשים במפתחות הציבוריים של Google (שזמינים בפורמט JWK או PEM) כדי לאמת את החתימה של האסימון.

לאחר הפענוח, טענת הנכוֹנוּת (assertion) של ה-JWT נראית כמו הדוגמה הבאה:

{
  "sub": 1234567890,        // The unique ID of the user's Google Account
  "iss": "https://accounts.google.com",        // The assertion's issuer
  "aud": "123-abc.apps.googleusercontent.com", // Your server's client ID
  "iat": 233366400,         // Unix timestamp of the assertion's creation time
  "exp": 233370000,         // Unix timestamp of the assertion's expiration time
  "name": "Jan Jansen",
  "given_name": "Jan",
  "family_name": "Jansen",
  "email": "jan@gmail.com", // If present, the user's email address
  "locale": "en_US"
}

בנוסף לאימות החתימה של האסימון, חשוב לוודא שהמנפיק (השדה iss) של טענת הנכוֹנוּת (assertion) הוא https://accounts.google.com ושהקהל (השדה aud) הוא מזהה הלקוח שהוקצה לפעולה.

בודקים אם חשבון Google כבר קיים במערכת האימות

בודקים אם מתקיים אחד מהתנאים הבאים:

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

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

אם אין התאמה בין מזהה חשבון Google לבין כתובת האימייל שצוינה בטענת הנכוֹנוּת (assertion) משתמש במסד הנתונים, המשתמש עוד לא נרשם. במקרה כזה, נקודת הקצה של המרת האסימונים צריכה להגיב שגיאת HTTP 401 שמציינת error=user_not_found, כמו בדוגמה הבאה:

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=UTF-8

{
  "error":"user_not_found",
}
כש-Google מקבלת תגובה לשגיאה 401 עם השגיאה user_not_found, היא קוראת לנקודת הקצה של המרת האסימון עם הערך של הפרמטר intent שמוגדר ל-create ושולחת אסימון מזהה שכולל את פרטי הפרופיל של המשתמש עם הבקשה.

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

כשמשתמש צריך ליצור חשבון בשירות שלכם, Google שולחת בקשה לנקודת הקצה של המרת האסימונים שבה מצוין intent=create, כמו בדוגמה הבאה:

POST /token HTTP/1.1
Host: oauth2.example.com
Content-Type: application/x-www-form-urlencoded

response_type=token&grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&scope=SCOPES&intent=create&consent_code=CONSENT_CODE&assertion=JWT[&NEW_ACCOUNT_INFO]

הפרמטר assertion מכיל אסימון Web Token (JWT) שמספק טענת נכוֹנוּת (assertion) חתומה של הזהות של משתמש Google. ה-JWT מכיל מידע שכולל את מזהה חשבון Google של המשתמש, את השם ואת כתובת האימייל שלו, ואפשר להשתמש בו כדי ליצור חשבון חדש בשירות שלכם.

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

אימות ופענוח של טענת ה-JWT

אפשר לאמת ולפענח את טענת ה-JWT באמצעות ספריית פענוח JWT בשפה שלכם. משתמשים במפתחות הציבוריים של Google (שזמינים בפורמט JWK או PEM) כדי לאמת את החתימה של האסימון.

לאחר הפענוח, טענת הנכוֹנוּת (assertion) של ה-JWT נראית כמו הדוגמה הבאה:

{
  "sub": 1234567890,        // The unique ID of the user's Google Account
  "iss": "https://accounts.google.com",        // The assertion's issuer
  "aud": "123-abc.apps.googleusercontent.com", // Your server's client ID
  "iat": 233366400,         // Unix timestamp of the assertion's creation time
  "exp": 233370000,         // Unix timestamp of the assertion's expiration time
  "name": "Jan Jansen",
  "given_name": "Jan",
  "family_name": "Jansen",
  "email": "jan@gmail.com", // If present, the user's email address
  "locale": "en_US"
}

בנוסף לאימות החתימה של האסימון, חשוב לוודא שהמנפיק (השדה iss) של טענת הנכוֹנוּת (assertion) הוא https://accounts.google.com ושהקהל (השדה aud) הוא מזהה הלקוח שהוקצה לפעולה.

אימות פרטי המשתמש ויצירת חשבון חדש

בודקים אם מתקיים אחד מהתנאים הבאים:

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

אם אחד מהתנאים מתקיים, מבקשים מהמשתמש לקשר את החשבון הקיים לחשבון Google שלו. לשם כך, מגיבים לבקשה עם שגיאת HTTP 401 ומציינים את error=linking_error ואת כתובת האימייל של המשתמש כ-login_hint, כמו בדוגמה הבאה:

HTTP/1.1 401 Unauthorized
Content-Type: application/json;charset=UTF-8

{
  "error":"linking_error",
  "login_hint":"foo@bar.com"
}

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

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

{
  "token_type": "Bearer",
  "access_token": "ACCESS_TOKEN",
  
  "expires_in": SECONDS_TO_EXPIRATION
}

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

בודקים אם המשתמש מאומת ומתחילים בתהליך קישור החשבון

  1. פותחים את הפרויקט ב-Actions Builder ב-Actions Console.
  2. יוצרים סצנה חדשה כדי להתחיל את קישור החשבונות בפעולה:
    1. לוחצים על סצנות.
    2. לוחצים על הסמל הוספה (+) כדי להוסיף סצנה חדשה.
  3. בסצנה החדשה שנוצרה, לוחצים על סמל ההוספה של Conditions.
  4. אפשר להוסיף תנאי שבודק אם המשתמש שמשויך לשיחה הוא משתמש מאומת. אם הבדיקה נכשלת, הפעולה לא יכולה לבצע קישור חשבונות במהלך השיחה. במקום זאת, אתם אמורים לקבל גישה לפונקציונליות שלא מחייבת קישור חשבונות.
    1. בשדה Enter new expression בקטע תנאי, מזינים את הלוגיקה הבאה: user.verificationStatus != "VERIFIED"
    2. בקטע Transition, בוחרים סצנה שלא מחייבת קישור של חשבונות, או סצנה שהיא נקודת הכניסה לפונקציונליות לאורחים בלבד.

  1. לוחצים על סמל ההוספה עבור תנאים.
  2. אפשר להוסיף תנאי שמפעיל תהליך של קישור חשבון אם למשתמש לא משויכת זהות.
    1. בשדה Enter new expression בקטע תנאי, מזינים את הלוגיקה הבאה: user.verificationStatus == "VERIFIED"
    2. בקטע מעבר, בוחרים בסצנה של המערכת קישור חשבונות.
    3. לוחצים על שמירה.

אחרי השמירה, תתווסף לפרויקט סצנה חדשה של מערכת קישור חשבונות בשם <SceneName>_AccountLinking.

התאמה אישית של הסצנה של קישור החשבונות

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

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

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

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

טיפול בבקשות גישה לנתונים

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