با توابع مسدود کردن، احراز هویت Firebase را گسترش دهید


توابع مسدود کردن به شما امکان می دهند کد سفارشی را اجرا کنید که نتیجه ثبت نام یا ورود کاربر به برنامه شما را تغییر می دهد. برای مثال، می‌توانید از احراز هویت کاربر در صورت عدم رعایت معیارهای خاص جلوگیری کنید یا اطلاعات کاربر را قبل از بازگرداندن آن به برنامه مشتری خود به‌روزرسانی کنید.

قبل از اینکه شروع کنی

برای استفاده از توابع مسدود کردن، باید پروژه Firebase خود را به Firebase Authentication با Identity Platform ارتقا دهید. اگر قبلاً ارتقاء نداده اید، ابتدا این کار را انجام دهید.

درک عملکردهای مسدود کردن

می توانید توابع مسدود کردن را برای دو رویداد ثبت کنید:

  • beforeCreate : قبل از ذخیره شدن کاربر جدید در پایگاه داده احراز هویت Firebase و قبل از بازگرداندن رمز به برنامه مشتری شما، فعال می شود.

  • beforeSignIn : پس از تأیید اعتبار کاربر، اما قبل از اینکه Firebase Authentication یک رمز شناسه را به برنامه مشتری شما بازگرداند، فعال می شود. اگر برنامه شما از احراز هویت چند عاملی استفاده می‌کند، این تابع پس از تأیید فاکتور دوم توسط کاربر فعال می‌شود. توجه داشته باشید که ایجاد یک کاربر جدید علاوه بر beforeSignIn ، قبل beforeCreate نیز فعال می شود.

هنگام استفاده از توابع مسدود کردن موارد زیر را در نظر داشته باشید:

  • تابع شما باید در عرض 7 ثانیه پاسخ دهد. پس از 7 ثانیه، Firebase Authentication خطایی را برمی‌گرداند و عملیات کلاینت با شکست مواجه می‌شود.

  • کدهای پاسخ HTTP غیر از 200 به برنامه های مشتری شما منتقل می شوند. اطمینان حاصل کنید که کد مشتری شما خطاهایی را که عملکرد شما می تواند برگرداند، کنترل کند.

  • توابع برای همه کاربران پروژه شما اعمال می شود، از جمله هر کدام که در یک مستاجر وجود دارد. احراز هویت Firebase اطلاعاتی در مورد کاربران تابع شما، از جمله مستاجرینی که به آنها تعلق دارند، ارائه می‌کند، بنابراین می‌توانید مطابق با آن پاسخ دهید.

  • پیوند دادن یک ارائه‌دهنده هویت دیگر به یک حساب، هر توابع ثبت‌شده beforeSignIn را دوباره فعال می‌کند.

  • احراز هویت ناشناس و سفارشی باعث ایجاد توابع مسدود نمی شود.

یک تابع مسدود کننده را مستقر کنید

برای درج کد سفارشی خود در جریان های احراز هویت کاربر، توابع مسدود کننده را مستقر کنید. هنگامی که توابع مسدود کردن شما مستقر شدند، کد سفارشی شما باید با موفقیت تکمیل شود تا احراز هویت و ایجاد کاربر موفقیت آمیز باشد.

شما یک تابع مسدود کننده را به همان روشی که هر تابعی را استقرار می دهید، مستقر می کنید. (برای جزئیات به صفحه شروع عملکردهای ابری مراجعه کنید). به طور خلاصه:

  1. توابع Cloud را بنویسید که رویداد beforeCreate ، رویداد beforeSignIn یا هر دو را مدیریت می کند.

    برای مثال، برای شروع، می‌توانید توابع no-op زیر را به index.js اضافه کنید:

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

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

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

    مثال‌های بالا اجرای منطق احراز هویت سفارشی را حذف کرده‌اند. برای یادگیری نحوه اجرای توابع مسدود کردن و سناریوهای رایج برای مثال‌های خاص، بخش‌های زیر را ببینید.

  2. توابع خود را با استفاده از 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 ها از مناطق جغرافیایی مختلف هستند - می توانید از کاربر بخواهید دوباره وارد شود.

  1. از ادعاهای جلسه برای ردیابی آدرس IP که کاربر با آن وارد می شود استفاده کنید:

    Node.js

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

  2. هنگامی که کاربر سعی می کند به منابعی که نیاز به احراز هویت با احراز هویت Firebase دارند دسترسی پیدا کند، آدرس 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',
 };
});