טריגרים לחסימת אימות


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

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

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

הסבר על פונקציות חסימה

אפשר לרשום פונקציות חסימה לאירועים הבאים:

  • ‫beforeCreate: מופעל לפני שמשתמש חדש נשמר במסד הנתונים Firebase Authentication, ולפני שאסימון מוחזר לאפליקציית הלקוח.

  • ‫beforeSignIn: מופעל אחרי אימות פרטי הכניסה של המשתמש, אבל לפני ש-Firebase Authentication מחזיר טוקן מזהה לאפליקציית הלקוח. אם האפליקציה משתמשת באימות רב-שלבי, הפונקציה מופעלת אחרי שהמשתמש מאמת את השלב השני. שימו לב: יצירת משתמש חדש מפעילה גם את beforeSignIn, בנוסף ל-beforeCreate.

  • ‫beforeEmail (Node.js בלבד): מופעל לפני שאימייל (לדוגמה,
    אימייל של כניסה או איפוס סיסמה) נשלח למשתמש.

  • ‫beforeSms (Node.js בלבד): מופעל לפני שליחת הודעת SMS למשתמש, במקרים כמו אימות רב-שלבי.

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

  • הפונקציה צריכה להגיב תוך 7 שניות. אחרי 7 שניות, הפונקציה Firebase Authentication מחזירה שגיאה, והפעולה בצד הלקוח נכשלת.

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

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

  • קישור של ספק זהויות אחר לחשבון מפעיל מחדש את כל הפונקציות הרשומות של beforeSignIn.

  • אימות אנונימי ואימות מותאם אישית לא מפעילים פונקציות חסימה.

פריסת פונקציית חסימה

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

פריסת פונקציית חסימה מתבצעת באותו אופן כמו פריסה של כל פונקציה אחרת. (פרטים נוספים מופיעים בדף Cloud Functions תחילת העבודה). בקצרה:

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

    לדוגמה, כדי להתחיל, אפשר להוסיף פונקציה ללא פעולה כמו הפונקציה הבאה ל-index.js:

    const functions = require('firebase-functions/v1');

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  // TODO
});

The above example has omitted the implementation of custom auth logic. See
the following sections to learn how to implement your blocking functions and
[Common scenarios](#common-scenarios) for specific examples.

  1. פורסים את הפונקציות באמצעות Firebase CLI:

    firebase deploy --only functions

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

קבלת מידע על משתמשים והקשר

האירועים beforeSignIn ו-beforeCreate מספקים אובייקטים של User ו-EventContext שמכילים מידע על המשתמש שנכנס לחשבון. אפשר להשתמש בערכים האלה בקוד כדי לקבוע אם לאפשר את המשך הפעולה.

רשימת המאפיינים שזמינים באובייקט User מופיעה בהפניית API של UserRecord.

אובייקט EventContext מכיל את המאפיינים הבאים:

שם תיאור דוגמה
locale האזור של האפליקציה. אפשר להגדיר את הלוקאל באמצעות ה-SDK של הלקוח או על ידי העברת כותרת הלוקאל ב-REST API. fr או sv-SE
ipAddress כתובת ה-IP של המכשיר שממנו משתמש הקצה נרשם או נכנס לחשבון. 114.14.200.1
userAgent סוכן המשתמש שמפעיל את פונקציית החסימה. Mozilla/5.0 (X11; Linux x86_64)
eventId המזהה הייחודי של האירוע. rWsyPtolplG2TBFoOkkgyg
eventType סוג האירוע. המידע הזה כולל את שם האירוע, למשל beforeSignIn או beforeCreate, ואת שיטת הכניסה המשויכת שבה נעשה שימוש, כמו Google או אימייל/סיסמה. providers/cloud.auth/eventTypes/user.beforeSignIn:password
authType תמיד USER. USER
resource הפרויקט או הדייר Firebase Authentication. projects/project-id/tenants/tenant-id
timestamp השעה שבה האירוע הופעל, בפורמט של מחרוזת RFC 3339. Tue, 23 Jul 2019 21:10:57 GMT
additionalUserInfo אובייקט שמכיל מידע על המשתמש. AdditionalUserInfo
credential אובייקט שמכיל מידע על פרטי הכניסה של המשתמש. AuthCredential

חסימת הרשמה או כניסה לחשבון

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

Node.js 

throw new functions.auth.HttpsError('permission-denied');

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

שם קוד הודעה
invalid-argument 400 הלקוח ציין ארגומנט לא חוקי.
failed-precondition 400 לא ניתן לבצע את הבקשה במצב הנוכחי של המערכת.
out-of-range 400 הלקוח ציין טווח לא חוקי.
unauthenticated 401 טוקן OAuth חסר, לא חוקי או שתוקפו פג.
permission-denied 403 ללקוח אין הרשאה מספיקה.
not-found 404 המשאב שצוין לא נמצא.
aborted 409 התנגשות מסוג בו-זמניות (Concurrency), כגון התנגשות בפעולה read-modify-write (קריאה-שינוי-כתיבה).
already-exists 409 המשאב שהלקוח ניסה ליצור כבר קיים.
resource-exhausted 429 מכסת המשאבים מוצתה או שהגבלת הקצב של יצירת הבקשות תמוצה בקרוב.
cancelled 499 הבקשה בוטלה על ידי הלקוח.
data-loss 500 פגם בנתונים או אובדן נתונים שלא ניתן לשחזר.
unknown 500 שגיאת שרת לא ידועה.
internal 500 שגיאת שרת פנימית.
not-implemented 501 שיטת ה-API לא הוטמעה על ידי השרת.
unavailable 503 השירות אינו זמין.
deadline-exceeded 504 המועד האחרון לשליחת הבקשה חלף.

אפשר גם לציין הודעת שגיאה מותאמת אישית:

Node.js 

throw new functions.auth.HttpsError('permission-denied', 'Unauthorized request origin!');

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

Node.js 

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  // (If the user is authenticating within a tenant context, the tenant ID can be determined from
  // user.tenantId or from context.resource, e.g. 'projects/project-id/tenant/tenant-id-1')

  // Only users of a specific domain can sign up.
  if (user.email.indexOf('@acme.com') === -1) {
    throw new functions.auth.HttpsError('invalid-argument', `Unauthorized email "${user.email}"`);
  }
});

לא משנה אם משתמשים בהודעת ברירת מחדל או בהודעה בהתאמה אישית, Cloud Functions עוטף את השגיאה ומחזיר אותה ללקוח כשגיאה פנימית. לדוגמה:

throw new functions.auth.HttpsError('invalid-argument', `Unauthorized email user@evil.com}`);

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

JavaScript 

// Blocking functions can also be triggered in a multi-tenant context before user creation.
// firebase.auth().tenantId = 'tenant-id-1';
firebase.auth().createUserWithEmailAndPassword('johndoe@example.com', 'password')
  .then((result) => {
    result.user.getIdTokenResult()
  })
  .then((idTokenResult) => {
    console.log(idTokenResult.claim.admin);
  })
  .catch((error) => {
    if (error.code !== 'auth/internal-error' && error.message.indexOf('Cloud Function') !== -1) {
      // Display error.
    } else {
      // Registration succeeds.
    }
  });

שינוי משתמש

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

כדי לשנות משתמש, מחזירים אובייקט מ-event handler שמכיל את השדות שרוצים לשנות. אפשר לשנות את השדות הבאים:

  • displayName
  • disabled
  • emailVerified
  • photoUrl
  • customClaims
  • ‫sessionClaims (beforeSignIn בלבד)

חוץ מהשדה sessionClaims, כל השדות שמשתנים נשמרים במסד הנתונים של Firebase Authentication, כלומר הם נכללים באסימון התגובה ונשמרים בין סשנים של משתמשים.

בדוגמה הבאה מוצג איך מגדירים שם לתצוגה כברירת מחדל:

Node.js 

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  return {
    // If no display name is provided, set it to "Guest".
    displayName: user.displayName || 'Guest';
  };
});

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

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

פרטי כניסה ונתונים של OAuth שאנחנו תומכים בהם

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

ספק זהות (IdP) אסימון מזהה טוקן גישה מועד תפוגה סוד הטוקן טוקן רענון הצהרות על כניסה לחשבון
Google כן כן כן לא כן לא
Facebook לא כן כן לא לא לא
Twitter לא כן לא כן לא לא
GitHub לא כן לא לא לא לא
Microsoft כן כן כן לא כן לא
LinkedIn לא כן כן לא לא לא
Yahoo כן כן כן לא כן לא
Apple כן כן כן לא כן לא
SAML לא לא לא לא לא כן
OIDC כן כן כן לא כן כן

אסימוני רענון

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

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

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

ספקי OIDC גנריים

כשמשתמש נכנס באמצעות ספק OIDC גנרי, פרטי הכניסה הבאים מועברים:

  • ‫ID token: מסופק אם נבחר התהליך id_token.
  • אסימון גישה: מופיע אם נבחר תהליך קבלת קוד. הערה: נכון לעכשיו, תהליך העברת הקוד נתמך רק דרך REST API.
  • אסימון רענון: מופיע אם נבחר היקף ההרשאות offline_access.

דוגמה:

const provider = new firebase.auth.OAuthProvider('oidc.my-provider');
provider.addScope('offline_access');
firebase.auth().signInWithPopup(provider);

Google

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

  • אסימון מזהה
  • טוקן גישה
  • רענון הטוקן: מועבר רק אם מתבקשים הפרמטרים המותאמים אישית הבאים:
    • access_type=offline
    • ‫prompt=consent, אם המשתמש הביע הסכמה בעבר ולא נדרש היקף חדש

דוגמה:

const provider = new firebase.auth.GoogleAuthProvider();
provider.setCustomParameters({
  'access_type': 'offline',
  'prompt': 'consent'
});
firebase.auth().signInWithPopup(provider);

מידע נוסף על טוקנים לרענון של Google

Facebook

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

GitHub

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

  • טוקן גישה: לא פג התוקף שלו אלא אם הוא בוטל.

Microsoft

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

  • אסימון מזהה
  • טוקן גישה
  • Refresh token: מועבר לפונקציית החסימה אם נבחר offline_access scope.

דוגמה:

const provider = new firebase.auth.OAuthProvider('microsoft.com');
provider.addScope('offline_access');
firebase.auth().signInWithPopup(provider);

Yahoo

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

  • אסימון מזהה
  • טוקן גישה
  • טוקן רענון

LinkedIn

כשמשתמש נכנס באמצעות LinkedIn, פרטי הכניסה הבאים מועברים:

  • טוקן גישה

Apple

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

  • אסימון מזהה
  • טוקן גישה
  • טוקן רענון

תרחישים נפוצים

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

ההרשמה מותרת רק מדומיין ספציפי

בדוגמה הבאה מוצג איך למנוע ממשתמשים שלא שייכים לדומיין example.com להירשם לאפליקציה:

Node.js 

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (!user.email || user.email.indexOf('@example.com') === -1) {
    throw new functions.auth.HttpsError(
      'invalid-argument', `Unauthorized email "${user.email}"`);
  }
});

חסימת משתמשים עם כתובות אימייל לא מאומתות מלהירשם

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

Node.js 

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (user.email && !user.emailVerified) {
    throw new functions.auth.HttpsError(
      'invalid-argument', `Unverified email "${user.email}"`);
  }
});

חובת אימות של כתובת האימייל במהלך הרישום

בדוגמה הבאה מוצג איך לדרוש ממשתמש לאמת את כתובת האימייל שלו אחרי ההרשמה:

Node.js 

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  const locale = context.locale;
  if (user.email && !user.emailVerified) {
    // Send custom email verification on sign-up.
    return admin.auth().generateEmailVerificationLink(user.email).then((link) => {
      return sendCustomVerificationEmail(user.email, link, locale);
    });
  }
});

exports.beforeSignIn = functions.auth.user().beforeSignIn((user, context) => {
 if (user.email && !user.emailVerified) {
   throw new functions.auth.HttpsError(
     'invalid-argument', `"${user.email}" needs to be verified before access is granted.`);
  }
});

התייחסות לאימיילים מסוימים מספקי זהויות כאל אימיילים מאומתים

בדוגמה הבאה מוצג איך להתייחס לכתובות אימייל של משתמשים מספקי זהויות מסוימים כאל כתובות מאומתות:

Node.js 

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (user.email && !user.emailVerified && context.eventType.indexOf(':facebook.com') !== -1) {
    return {
      emailVerified: true,
    };
  }
});

חסימת כניסה מכתובות IP מסוימות

בדוגמה הבאה אפשר לראות איך לחסום כניסה ל-Google מטווחים מסוימים של כתובות IP:

Node.js 

exports.beforeSignIn = functions.auth.user().beforeSignIn((user, context) => {
  if (isSuspiciousIpAddress(context.ipAddress)) {
    throw new functions.auth.HttpsError(
      'permission-denied', 'Unauthorized access!');
  }
});

הגדרת טענות מותאמות אישית וטענות של סשן

בדוגמה הבאה מוצגות הצהרות מותאמות אישית והצהרות של סשן:

Node.js 

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (context.credential &&
      context.credential.providerId === 'saml.my-provider-id') {
    return {
      // Employee ID does not change so save in persistent claims (stored in
      // Auth DB).
      customClaims: {
        eid: context.credential.claims.employeeid,
      },
      // Copy role and groups to token claims. These will not be persisted.
      sessionClaims: {
        role: context.credential.claims.role,
        groups: context.credential.claims.groups,
      }
    }
  }
});

מעקב אחרי כתובות IP כדי לזהות פעילות חשודה

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

  1. משתמשים בטענות לגבי סשן כדי לעקוב אחרי כתובת ה-IP שדרכה המשתמש נכנס לחשבון:

    Node.js 

    exports.beforeSignIn = functions.auth.user().beforeSignIn((user, context) => {
  return {
    sessionClaims: {
      signInIpAddress: context.ipAddress,
    },
  };
});

  2. כשמשתמש מנסה לגשת למשאבים שנדרש אימות באמצעות Firebase Authentication, משווים את כתובת ה-IP בבקשה לכתובת ה-IP ששימשה לכניסה:

    Node.js 

    app.post('/getRestrictedData', (req, res) => {
  // Get the ID token passed.
  const idToken = req.body.idToken;
  // Verify the ID token, check if revoked and decode its payload.
  admin.auth().verifyIdToken(idToken, true).then((claims) => {
    // Get request IP address
    const requestIpAddress = req.connection.remoteAddress;
    // Get sign-in IP address.
    const signInIpAddress = claims.signInIpAddress;
    // Check if the request IP address origin is suspicious relative to
    // the session IP addresses. The current request timestamp and the
    // auth_time of the ID token can provide additional signals of abuse,
    // especially if the IP address suddenly changed. If there was a sudden
    // geographical change in a short period of time, then it will give
    // stronger signals of possible abuse.
    if (!isSuspiciousIpAddressChange(signInIpAddress, requestIpAddress)) {
      // Suspicious IP address change. Require re-authentication.
      // You can also revoke all user sessions by calling:
      // admin.auth().revokeRefreshTokens(claims.sub).
      res.status(401).send({error: 'Unauthorized access. Please login again!'});
    } else {
      // Access is valid. Try to return data.
      getData(claims).then(data => {
        res.end(JSON.stringify(data);
      }, error => {
        res.status(500).send({ error: 'Server error!' })
      });
    }
  });
});

בדיקת תמונות של משתמשים

בדוגמה הבאה אפשר לראות איך לנקות את תמונות הפרופיל של המשתמשים:

Node.js 

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (user.photoURL) {
    return isPhotoAppropriate(user.photoURL)
      .then((status) => {
        if (!status) {
          // Sanitize inappropriate photos by replacing them with guest photos.
          // Users could also be blocked from sign-up, disabled, etc.
          return {
            photoUrl: PLACEHOLDER_GUEST_PHOTO_URL,
          };
        }
      });
});

מידע נוסף על זיהוי תמונות וניקוי שלהן זמין במאמרים בנושא Cloud Vision.

גישה לפרטי הכניסה של OAuth של ספק הזהויות של משתמש

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

Node.js 

const {OAuth2Client} = require('google-auth-library');
const {google} = require('googleapis');
// ...
// Initialize Google OAuth client.
const keys = require('./oauth2.keys.json');
const oAuth2Client = new OAuth2Client(
  keys.web.client_id,
  keys.web.client_secret
);

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (context.credential &&
      context.credential.providerId === 'google.com') {
    // Store the refresh token for later offline use.
    // These will only be returned if refresh tokens credentials are included
    // (enabled by Cloud console).
    return saveUserRefreshToken(
        user.uid,
        context.credential.refreshToken,
        'google.com'
      )
      .then(() => {
        // Blocking the function is not required. The function can resolve while
        // this operation continues to run in the background.
        return new Promise((resolve, reject) => {
          // For this operation to succeed, the appropriate OAuth scope should be requested
          // on sign in with Google, client-side. In this case:
          // https://www.googleapis.com/auth/calendar
          // You can check granted_scopes from within:
          // context.additionalUserInfo.profile.granted_scopes (space joined list of scopes).

          // Set access token/refresh token.
          oAuth2Client.setCredentials({
            access_token: context.credential.accessToken,
            refresh_token: context.credential.refreshToken,
          });
          const calendar = google.calendar('v3');
          // Setup Onboarding event on user's calendar.
          const event = {/** ... */};
          calendar.events.insert({
            auth: oauth2client,
            calendarId: 'primary',
            resource: event,
          }, (err, event) => {
            // Do not fail. This is a best effort approach.
            resolve();
          });
      });
    })
  }
});

ביטול פסיקת reCAPTCHA Enterprise לפעולת משתמש

בדוגמה הבאה מוצג איך לשנות את פסק הדין של reCAPTCHA Enterprise לגבי תהליכי משתמש נתמכים.

במאמר הפעלת reCAPTCHA Enterprise מוסבר איך לשלב את reCAPTCHA Enterprise עם Firebase Authentication.

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

Node.js 

const functions = require("firebase-functions/v1");
exports.beforesmsv1 = functions.auth.user().beforeSms((context) => {
 if (
   context.smsType === "SIGN_IN_OR_SIGN_UP" &&
   context.additionalUserInfo.phoneNumber.includes('+91')
 ) {
   return {
     recaptchaActionOverride: "ALLOW",
   };
 }

 // Allow users to sign in with recaptcha score greater than 0.5
 if (event.additionalUserInfo.recaptchaScore > 0.5) {
   return {
     recaptchaActionOverride: 'ALLOW',
   };
 }

 // Block all others.
 return  {
   recaptchaActionOverride: 'BLOCK',
 }
});