פונקציות חסימה מאפשרות להפעיל קוד מותאם אישית שמשנה את התוצאה רישום אפליקציה או כניסה לאפליקציה. לדוגמה, אפשר למנוע ממשתמש או אם הם לא עומדים בקריטריונים מסוימים, או מעדכנים את לפני החזרתו לאפליקציית הלקוח.
לפני שמתחילים
כדי להשתמש בפונקציות חסימה צריך לשדרג את פרויקט 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 תחילת העבודה לקבלת פרטים נוספים). בקצרה:
כותבים את הפקודה 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 });
בדוגמאות שלמעלה, השמטת את היישום של לוגיקת אימות מותאם אישית. בקטע הבא מוסבר איך מטמיעים את פונקציות החסימה, ובתרחישי נפוצים מפורטות דוגמאות ספציפיות.
פורסים את הפונקציות באמצעות ה-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) | אסימון מזהה | טוקן גישה | מועד תפוגה | סוד האסימון | רענון האסימון | תלונות על כניסה לחשבון |
---|---|---|---|---|---|---|
כן | כן | כן | לא | כן | לא | |
לא | כן | כן | לא | לא | לא | |
לא | כן | לא | כן | לא | לא | |
GitHub | לא | כן | לא | לא | לא | לא |
Microsoft | כן | כן | כן | לא | כן | לא |
לא | כן | כן | לא | לא | לא | |
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, פרטי הכניסה הבאים מועברים:
- אסימון מזהה
- אסימון גישה
- אסימון רענון: צוין רק אם הפרמטרים המותאמים אישית הבאים
נשלחה בקשה:
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 ואיך ניתן להחליף אותם אסימונים לטווח ארוך.
GitHub
כשמשתמש נכנס באמצעות GitHub, פרטי הכניסה הבאים יועברו:
- אסימון גישה: התוקף שלו פג, אלא אם הוא מבוטל.
Microsoft
כשמשתמש נכנס באמצעות Microsoft, פרטי הכניסה הבאים יועברו:
- אסימון מזהה
- אסימון גישה
- אסימון רענון: מועבר לפונקציית החסימה אם
היקף הרשאות של
offline_access
מסומנת.
דוגמה:
const provider = new firebase.auth.OAuthProvider('microsoft.com');
provider.addScope('offline_access');
firebase.auth().signInWithPopup(provider);
Yahoo
כשמשתמש נכנס באמצעות Yahoo, פרטי הכניסה הבאים יועברו ללא פרמטרים או היקפים מותאמים אישית:
- אסימון מזהה
- אסימון גישה
- אסימון רענון
כשמשתמש נכנס באמצעות 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 מגיעות ממיקומים גיאוגרפיים שונים אזורים – אפשר לבקש מהמשתמש להיכנס שוב לחשבון.
אפשר להשתמש בהצהרות על זכויות יוצרים כדי לעקוב אחר כתובת ה-IP שדרכה המשתמש נכנס:
Node.js
exports.beforeSignIn = functions.auth.user().beforeSignIn((user, context) => { return { sessionClaims: { signInIpAddress: context.ipAddress, }, }; });
כשמשתמש מנסה לגשת למשאבים שמחייבים אימות באמצעות 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',
};
});