הרחבת האימות ב-Firebase באמצעות פונקציות חסימה


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. כותבים את הפקודה Cloud Functions שמטפלת באירוע beforeCreate, אירוע beforeSignIn, או את שניהם.

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

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

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

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

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

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

    firebase deploy --only functions

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

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

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

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

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

שם תיאור דוגמה
locale הלוקאל של האפליקציה אפשר להגדיר את הלוקאל באמצעות ב-SDK של הלקוח, או על ידי העברת כותרת הלוקאל ב-API ל-REST. 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), כמו התנגשות בין קריאה-שינוי-כתיבה.
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 והוחזר ללקוח.

כדי לשנות משתמש, צריך להחזיר אובייקט מה-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 בשני הגורמים שמטפלים באירועים, הערך שמוגדר ב-beforeSignIn מחליפה את הערך שהוגדר ב-beforeCreate. עבור sessionClaims בלבד, הם מועברים לטענות הנכונות של האסימון של הסשן הנוכחי, אבל לא נשמרים או מאוחסנים במסד הנתונים.

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

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

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

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

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

כדי להשתמש באסימון רענון בפונקציית חסימה, קודם עליך לבחור את בדף block Functions (פונקציות חסימה) במסוף Firebase.

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

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

ספקי OIDC גנריים

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

  • אסימון מזהה: יצוין אם התהליך id_token נבחר.
  • אסימון גישה: מסופק אם נבחר תהליך באמצעות קוד. שימו לב שהקוד קיימת כרגע תמיכה רק ב-API ל-REST.
  • אסימון רענון: מצוין אם היקף הרשאות של 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

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

  • אסימון גישה: מוחזר אסימון גישה ואפשר להחליף אותו אסימון גישה אחר. מידע נוסף על הסוגים השונים של אסימוני גישה נתמכים על ידי Facebook ואיך ניתן להחליף אותם אסימונים לטווח ארוך.

GitHub

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

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

Microsoft

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

דוגמה:

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 מסוימות

הדוגמה הבאה מראה איך חוסמים כניסה מטווחים מסוימים של כתובות 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 ומשתמשים בו כדי לקרוא לממשקי ה-API של יומן Google. אסימון הרענון מאוחסן לגישה אופליין.

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.

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

Node.js 

 const {
   auth,
 } = require("firebase-functions/v1");

exports.checkrecaptchaV1 = auth.user().beforeSignIn((userRecord, context) => {
 // Allow users with a specific email domain to sign in regardless of their recaptcha score.
 if (userRecord.email && userRecord.email.indexOf('@acme.com') === -1) {
   return {
     recaptchaActionOverride: 'ALLOW',
   };
 }

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

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