توابع مسدود کردن به شما امکان می دهند کد سفارشی را اجرا کنید که نتیجه ثبت نام یا ورود کاربر به برنامه شما را تغییر می دهد. برای مثال، میتوانید از احراز هویت کاربر در صورت عدم رعایت معیارهای خاص جلوگیری کنید یا اطلاعات کاربر را قبل از بازگرداندن آن به برنامه مشتری خود بهروزرسانی کنید.
قبل از شروع
برای استفاده از توابع مسدود کردن، باید پروژه Firebase خود را به Firebase Authentication with Identity Platform ارتقا دهید. اگر قبلاً ارتقاء نداده اید، ابتدا این کار را انجام دهید.
درک عملکردهای مسدود کردن
می توانید توابع مسدود کردن را برای دو رویداد ثبت کنید:
beforeCreate
: قبل از ذخیره شدن کاربر جدید در پایگاه داده Firebase Authentication و قبل از بازگرداندن رمز به برنامه مشتری شما، فعال می شود.beforeSignIn
: پس از تأیید اعتبار کاربر، اما قبل از اینکه Firebase Authentication یک رمز شناسه را به برنامه مشتری شما بازگرداند، فعال می شود. اگر برنامه شما از احراز هویت چند عاملی استفاده میکند، این تابع پس از تأیید فاکتور دوم توسط کاربر فعال میشود. توجه داشته باشید که ایجاد یک کاربر جدید علاوه برbeforeSignIn
،beforeCreate
به سیستم نیز فعال می شود.
هنگام استفاده از توابع مسدود کردن موارد زیر را در نظر داشته باشید:
تابع شما باید در عرض 7 ثانیه پاسخ دهد. پس از 7 ثانیه، Firebase Authentication خطایی را برمیگرداند و عملیات کلاینت با شکست مواجه میشود.
کدهای پاسخ HTTP غیر از
200
به برنامه های مشتری شما منتقل می شوند. اطمینان حاصل کنید که کد مشتری شما خطاهایی را که عملکرد شما می تواند برگرداند، کنترل کند.توابع برای همه کاربران پروژه شما اعمال می شود، از جمله هر کدام که در یک مستاجر وجود دارد. Firebase Authentication اطلاعاتی در مورد کاربران تابع شما، از جمله مستاجرینی که به آنها تعلق دارند، ارائه میکند، بنابراین میتوانید مطابق با آن پاسخ دهید.
پیوند دادن یک ارائهدهنده هویت دیگر به یک حساب، هر توابع ثبتشده
beforeSignIn
دوباره فعال میکند.احراز هویت ناشناس و سفارشی باعث ایجاد توابع مسدود نمی شود.
یک تابع مسدود کننده را مستقر کنید
برای درج کد سفارشی خود در جریان های احراز هویت کاربر، توابع مسدود کننده را مستقر کنید. هنگامی که توابع مسدود کردن شما مستقر شدند، کد سفارشی شما باید با موفقیت تکمیل شود تا احراز هویت و ایجاد کاربر موفقیت آمیز باشد.
شما یک تابع مسدود کننده را به همان روشی که هر تابعی را استقرار می دهید، مستقر می کنید. (برای جزئیات به صفحه شروع Cloud Functions مراجعه کنید). به طور خلاصه:
Cloud Functions بنویسید که رویداد
beforeCreate
، رویدادbeforeSignIn
یا هر دو را مدیریت می کند.برای مثال، برای شروع، میتوانید توابع no-op زیر را به
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 });
مثالهای بالا اجرای منطق احراز هویت سفارشی را حذف کردهاند. برای یادگیری نحوه اجرای توابع مسدود کردن و سناریوهای رایج برای مثالهای خاص، بخشهای زیر را ببینید.
توابع خود را با استفاده از Firebase CLI مستقر کنید:
firebase deploy --only functions
هر بار که توابع خود را به روز می کنید، باید آنها را مجدداً مستقر کنید.
دریافت اطلاعات کاربر و زمینه
رویدادهای beforeSignIn
و beforeCreate
اشیاء User
و EventContext
را ارائه می دهند که حاوی اطلاعاتی در مورد ورود کاربر به سیستم هستند. از این مقادیر در کد خود استفاده کنید تا تعیین کنید که آیا اجازه می دهید عملیات ادامه یابد یا خیر.
برای فهرستی از خصوصیات موجود در شی User
، به مرجع UserRecord
API مراجعه کنید.
شی 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 | تضاد همزمانی، مانند تداخل خواندن، اصلاح و نوشتن. |
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}`);
برنامه شما باید خطا را دریافت کند و مطابق آن با آن برخورد کند. به عنوان مثال:
جاوا اسکریپت
// 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 ذخیره شده و به مشتری بازگردانده می شود، تغییر دهید.
برای اصلاح یک کاربر، یک شی از کنترل کننده رویداد خود حاوی فیلدهایی برای اصلاح برگردانید. می توانید فیلدهای زیر را اصلاح کنید:
-
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 را برای مسدود کردن توابع از ارائهدهندگان هویت مختلف ارسال کنید. جدول زیر نشان می دهد که چه اعتبارنامه ها و داده هایی برای هر ارائه دهنده هویت پشتیبانی می شود:
ارائه دهنده هویت | شناسه شناسه | رمز دسترسی | زمان انقضا | رمز رمز | Refresh Token | ادعاهای ورود به سیستم |
---|---|---|---|---|---|---|
گوگل | بله | بله | بله | خیر | بله | خیر |
فیس بوک | خیر | بله | بله | خیر | خیر | خیر |
توییتر | خیر | بله | خیر | بله | خیر | خیر |
GitHub | خیر | بله | خیر | خیر | خیر | خیر |
مایکروسافت | بله | بله | بله | خیر | بله | خیر |
لینکدین | خیر | بله | بله | خیر | خیر | خیر |
یاهو | بله | بله | بله | خیر | بله | خیر |
اپل | بله | بله | بله | خیر | بله | خیر |
SAML | خیر | خیر | خیر | خیر | خیر | بله |
OIDC | بله | بله | بله | خیر | بله | بله |
بازخوانی نشانه ها
برای استفاده از یک نشانه رفرش در یک عملکرد مسدود کننده، ابتدا باید چک باکس را در صفحه عملکردهای مسدود کردن کنسول Firebase انتخاب کنید.
هنگام ورود مستقیم با اعتبار OAuth، مانند رمز شناسایی یا رمز دسترسی، هیچ ارائهدهنده هویتی، نشانههای Refresh را برگرداند. در این شرایط، همان اعتبار OAuth سمت کلاینت به تابع مسدود کننده منتقل می شود.
بخشهای زیر هر نوع ارائهدهنده هویت و اعتبارنامهها و دادههای پشتیبانیشده آنها را توضیح میدهد.
ارائه دهندگان عمومی OIDC
هنگامی که یک کاربر با یک ارائه دهنده OIDC عمومی وارد می شود، اعتبار زیر ارسال می شود:
- شناسه نشانه : در صورت انتخاب جریان
id_token
ارائه می شود. - نشانه دسترسی : در صورت انتخاب جریان کد ارائه می شود. توجه داشته باشید که جریان کد در حال حاضر فقط از طریق REST API پشتیبانی می شود.
- نشانه Refresh : در صورت انتخاب محدوده
offline_access
ارائه می شود.
مثال:
const provider = new firebase.auth.OAuthProvider('oidc.my-provider');
provider.addScope('offline_access');
firebase.auth().signInWithPopup(provider);
گوگل
هنگامی که کاربر با Google وارد می شود، اعتبار زیر ارسال می شود:
- شناسه شناسه
- نشانه دسترسی
- نشانه Refresh : فقط در صورت درخواست پارامترهای سفارشی زیر ارائه می شود:
-
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 وارد می شود، اعتبار زیر ارسال می شود:
- نشانه دسترسی : منقضی نمی شود مگر اینکه لغو شود.
مایکروسافت
هنگامی که یک کاربر با مایکروسافت وارد می شود، اعتبار زیر ارسال می شود:
- شناسه شناسه
- نشانه دسترسی
- نشانه Refresh : در صورت انتخاب محدوده
offline_access
، به تابع مسدود کننده منتقل می شود.
مثال:
const provider = new firebase.auth.OAuthProvider('microsoft.com');
provider.addScope('offline_access');
firebase.auth().signInWithPopup(provider);
یاهو
هنگامی که کاربر با یاهو وارد می شود، اعتبار زیر بدون هیچ گونه پارامتر یا محدوده سفارشی ارسال می شود:
- شناسه شناسه
- نشانه دسترسی
- نشانه تازه کردن
لینکدین
هنگامی که کاربر با لینکدین وارد می شود، اعتبار زیر ارسال می شود:
- نشانه دسترسی
اپل
هنگامی که کاربر با اپل وارد می شود، اعتبار زیر بدون هیچ گونه پارامتر یا محدوده سفارشی ارسال می شود:
- شناسه شناسه
- نشانه دسترسی
- نشانه تازه کردن
سناریوهای رایج
مثالهای زیر برخی از موارد استفاده رایج برای مسدود کردن توابع را نشان میدهند:
فقط اجازه ثبت از یک دامنه خاص
مثال زیر نشان می دهد که چگونه از ثبت نام کاربرانی که بخشی از دامنه 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 با Firebase Authentication به فعال کردن reCAPTCHA Enterprise مراجعه کنید.
توابع مسدود کردن را می توان برای اجازه یا مسدود کردن جریان ها بر اساس عوامل سفارشی استفاده کرد، در نتیجه نتیجه ارائه شده توسط 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',
};
});