Firebase 将于 4 月 9 日至 11 日重返 Cloud Next 大会。立即报名。

این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

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

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

قبل از شروع

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

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

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

beforeCreate : قبل از ذخیره شدن کاربر جدید در پایگاه داده Firebase Authentication و قبل از بازگرداندن رمز به برنامه مشتری شما، فعال می شود.
beforeSignIn : پس از تأیید اعتبار کاربر، اما قبل از اینکه Firebase Authentication یک رمز شناسه را به برنامه مشتری شما بازگرداند، فعال می شود. اگر برنامه شما از احراز هویت چند عاملی استفاده می‌کند، این تابع پس از تأیید فاکتور دوم توسط کاربر فعال می‌شود. توجه داشته باشید که ایجاد یک کاربر جدید علاوه بر beforeCreate ، beforeSignIn از ورود به سیستم نیز فعال می شود.
beforeEmail (فقط Node.js) : قبل از ایمیل فعال می شود (به عنوان مثال،
یک ایمیل ورود به سیستم یا تنظیم مجدد رمز عبور) برای یک کاربر ارسال می شود.
beforeSms (فقط Node.js) : قبل از ارسال پیام SMS به کاربر، برای مواردی مانند احراز هویت چند عاملی، فعال می شود.

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

تابع شما باید در عرض 7 ثانیه پاسخ دهد. پس از 7 ثانیه، Firebase Authentication خطایی را برمی‌گرداند و عملیات کلاینت با شکست مواجه می‌شود.
کدهای پاسخ HTTP غیر از 200 به برنامه های مشتری شما منتقل می شوند. اطمینان حاصل کنید که کد مشتری شما خطاهایی را که عملکرد شما می تواند برگرداند، کنترل کند.
توابع برای همه کاربران پروژه شما اعمال می شود، از جمله هر کدام که در یک مستاجر وجود دارد. Firebase Authentication اطلاعاتی در مورد کاربران تابع شما، از جمله مستاجرینی که به آنها تعلق دارند، ارائه می‌کند، بنابراین می‌توانید مطابق با آن پاسخ دهید.
پیوند دادن یک ارائه‌دهنده هویت دیگر به یک حساب، هر توابع ثبت‌شده beforeSignIn دوباره فعال می‌کند.
احراز هویت ناشناس و سفارشی باعث ایجاد توابع مسدود نمی شود.

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

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

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

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

به عنوان مثال، برای شروع، می توانید یک تابع no-op مانند زیر را به 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.

توابع خود را با استفاده از 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 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',
 }
});

قبل از شروع

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

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

beforeCreate : قبل از ذخیره کاربر جدید در پایگاه داده Firebase Authentication ، و قبل از بازگشت نشانه به برنامه مشتری شما ، محرک است.
beforeSignIn : پس از تأیید اعتبار کاربر ، محرک است ، اما قبل از Firebase Authentication نشانه شناسه را به برنامه مشتری خود بازگرداند. اگر برنامه شما از احراز هویت چند عاملی استفاده می کند ، این عملکرد بعد از تأیید کاربر عامل دوم خود را تحریک می کند. توجه داشته باشید که ایجاد یک کاربر جدید علاوه بر beforeSignIn ، علاوه بر beforeCreate ، باعث ایجاد طراحی شده نیز می شود.
beforeEmail (فقط node.js) : قبل از ایمیل شروع می شود (به عنوان مثال ،
ورود به سیستم یا ارسال مجدد رمز عبور) برای کاربر ارسال می شود.
beforeSms (فقط node.js) : قبل از ارسال پیام پیام کوتاه به کاربر ، برای مواردی مانند احراز هویت چند عاملی ارسال می شود.

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

عملکرد شما باید طی 7 ثانیه پاسخ دهد. پس از 7 ثانیه ، Firebase Authentication خطایی را برمی گرداند و عملکرد مشتری با شکست مواجه می شود.
کدهای پاسخ HTTP به غیر از 200 به برنامه های مشتری شما منتقل می شوند. اطمینان حاصل کنید که کد مشتری شما هرگونه خطایی را که عملکرد شما می تواند بازگرداند ، انجام می دهد.
توابع برای همه کاربران پروژه شما اعمال می شود ، از جمله هر یک از آنها در یک مستاجر . Firebase Authentication اطلاعاتی را در مورد کاربران در مورد عملکرد شما ، از جمله هر مستاجر متعلق به آنها ، ارائه می دهد ، بنابراین می توانید بر این اساس پاسخ دهید.
پیوند دادن یک ارائه دهنده هویت دیگر به یک حساب کارکردهای ثبت شده beforeSignIn دوباره تغییر می دهد.
احراز هویت ناشناس و سفارشی باعث جلوگیری از توابع مسدود کننده نمی شود.

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

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

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

تابعی را بنویسید که رویداد هدفمند را کنترل کند.

به عنوان مثال ، برای شروع ، می توانید یک تابع NO-OP مانند موارد زیر به 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.

توابع خود را با استفاده از 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`	درگیری همزمانی ، مانند یک درگیری با خواندن-نوشتن.
`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 Custom ، هنوز هم در پایگاه داده برای درخواست های آینده ادامه خواهد یافت.

از اعتبار و داده های OAUTH پشتیبانی می کند

شما می توانید اعتبار و داده های OAuth را برای مسدود کردن توابع از ارائه دهندگان مختلف هویت منتقل کنید. جدول زیر نشان می دهد که چه اعتبار و داده هایی برای هر ارائه دهنده هویت پشتیبانی می شود:

ارائه دهنده هویت	شناسه شناسه	رمز دسترسی	زمان انقضا	راز نشانه	Refresh Token	ادعای ورود به سیستم
گوگل	بله	بله	بله	خیر	بله	خیر
فیس بوک	خیر	بله	بله	خیر	خیر	خیر
توییتر	خیر	بله	خیر	بله	خیر	خیر
GitHub	خیر	بله	خیر	خیر	خیر	خیر
مایکروسافت	بله	بله	بله	خیر	بله	خیر
لینکدین	خیر	بله	بله	خیر	خیر	خیر
یاهو	بله	بله	بله	خیر	بله	خیر
اپل	بله	بله	بله	خیر	بله	خیر
SAML	خیر	خیر	خیر	خیر	خیر	بله
OIDC	بله	بله	بله	خیر	بله	بله

بازخوانی نشانه ها

برای استفاده از یک توکن تازه در یک عملکرد مسدود کردن ، ابتدا باید کادر انتخاب را در صفحه توابع مسدود کننده کنسول Firebase انتخاب کنید.

هنگام ورود مستقیم با اعتبار OAUTH ، مانند نشانه شناسه یا نشانه دسترسی ، نشانه های تازه سازی توسط هیچ یک از ارائه دهندگان هویت بازگردانده نمی شوند. در این شرایط ، همان اعتبار OAUTH سمت مشتری به عملکرد مسدود کردن منتقل می شود.

بخش های زیر هر نوع ارائه دهنده هویت و اعتبار و داده های پشتیبانی شده آنها را شرح می دهد.

ارائه دهندگان عمومی OIDC

هنگامی که کاربر با ارائه دهنده OIDC عمومی وارد سیستم می شود ، اعتبار زیر تصویب می شود:

ID Token : در صورت انتخاب جریان id_token .
Token Access : در صورت انتخاب جریان کد ، به شرط آنکه جریان باشد. توجه داشته باشید که جریان کد فقط از طریق API REST پشتیبانی می شود.
Token Token : در صورت انتخاب دامنه offline_access .

مثال:

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

گوگل

هنگامی که کاربر با Google وارد سیستم می شود ، اعتبار زیر تصویب می شود:

شناسه شناسه
نشانه دسترسی
Token Token : فقط در صورت درخواست پارامترهای سفارشی زیر ارائه می شود:
- access_type=offline
- prompt=consent ، اگر کاربر قبلاً رضایت داده و از دامنه جدیدی درخواست نشده است

مثال:

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

درباره نشانه های Google Refresh بیشتر بدانید.

فیس بوک

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

Token Access : یک نشانه دسترسی بازگردانده می شود که می تواند برای یک نشانه دسترسی دیگر رد و بدل شود. در مورد انواع مختلف نشانه های دسترسی پشتیبانی شده توسط فیس بوک و اینکه چگونه می توانید آنها را برای نشانه های طولانی مدت مبادله کنید ، بیشتر بدانید.

GitHub

هنگامی که یک کاربر با GitHub وارد می شود ، اعتبار زیر تصویب می شود:

Access Token : مگر اینکه ابطال شود منقضی نمی شود.

مایکروسافت

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

شناسه شناسه
نشانه دسترسی
Refresh Token : در صورت انتخاب دامنه offline_access به عملکرد مسدود کردن منتقل می شود.

مثال:

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

یاهو

هنگامی که کاربر با یاهو وارد سیستم می شود ، اعتبار زیر بدون هیچ گونه پارامتری سفارشی یا دامنه منتقل می شود:

شناسه شناسه
نشانه دسترسی
نشانه تازه کردن

لینکدین

هنگامی که یک کاربر با LinkedIn وارد می شود ، اعتبار زیر تصویب می شود:

نشانه دسترسی

اپل

هنگامی که کاربر با اپل وارد سیستم می شود ، اعتبار زیر بدون هیچ گونه پارامتری سفارشی یا دامنه منتقل می شود:

شناسه شناسه
نشانه دسترسی
نشانه تازه کردن

سناریوهای رایج

مثالهای زیر برخی موارد استفاده متداول را برای مسدود کردن توابع نشان می دهد:

فقط اجازه ثبت نام از یک دامنه خاص

مثال زیر نشان می دهد که چگونه می توان از کاربرانی که جزئی از دامنه 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 برخی از محدوده های 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 استفاده می کند. Token Refresh برای دسترسی آفلاین ذخیره می شود.

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 برای عملکرد کاربر

مثال زیر نحوه غلبه بر حکم سازمانی Recaptcha برای جریان کاربر پشتیبانی شده را نشان می دهد.

برای کسب اطلاعات بیشتر در مورد ادغام شرکت Recaptcha با احراز هویت Firebase ، به Enable Recaptcha Enterprise مراجعه کنید.

توابع مسدود کردن می تواند برای اجازه یا مسدود کردن جریان بر اساس فاکتورهای سفارشی استفاده شود ، در نتیجه نتیجه ارائه شده توسط 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',
 }
});