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

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

قبل از شروع

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

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

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

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

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

• beforeEmail (فقط Node.js) : قبل از ایمیل فعال می شود (به عنوان مثال،
  یک ایمیل ورود به سیستم یا تنظیم مجدد رمز عبور) برای یک کاربر ارسال می شود.

• beforeSms (فقط Node.js) : قبل از ارسال پیام SMS به کاربر، برای مواردی مانند احراز هویت چند عاملی، فعال می شود.

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

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

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

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

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

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

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

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

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

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

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

1. توابع خود را با استفاده از Firebase CLI مستقر کنید:

   firebase deploy --only functions
   

   هر بار که توابع خود را به روز می کنید، باید آنها را مجدداً مستقر کنید.

دریافت اطلاعات کاربر و زمینه

رویدادهای beforeSignIn و beforeCreate اشیاء User و EventContext را ارائه می دهند که حاوی اطلاعاتی در مورد ورود کاربر به سیستم هستند. از این مقادیر در کد خود استفاده کنید تا تعیین کنید که آیا اجازه می دهید عملیات ادامه یابد یا خیر.

برای فهرستی از خصوصیات موجود در شی User ، به مرجع UserRecord API مراجعه کنید.

شی EventContext دارای ویژگی های زیر است:

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

برای مسدود کردن تلاش برای ثبت نام یا ورود به سیستم، یک HttpsError را در تابع خود پرتاب کنید. به عنوان مثال:

throw new functions.auth.HttpsError('permission-denied');

جدول زیر خطاهایی را که می توانید مطرح کنید به همراه پیام خطای پیش فرض آنها فهرست می کند:

همچنین می توانید یک پیام خطای سفارشی را مشخص کنید:

throw new functions.auth.HttpsError('permission-denied', 'Unauthorized request origin!');

مثال زیر نشان می دهد که چگونه می توان کاربرانی را که در دامنه خاصی نیستند از ثبت نام برای برنامه خود مسدود کرد:

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 ذخیره می‌شوند، به این معنی که در نشانه پاسخ گنجانده شده و بین جلسات کاربر باقی می‌مانند.

مثال زیر نحوه تنظیم یک نام نمایشی پیش فرض را نشان می دهد:

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 را برای مسدود کردن توابع از ارائه‌دهندگان هویت مختلف ارسال کنید. جدول زیر نشان می دهد که چه اعتبارنامه ها و داده هایی برای هر ارائه دهنده هویت پشتیبانی می شود:

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

برای استفاده از یک نشانه رفرش در یک عملکرد مسدود کننده، ابتدا باید چک باکس را در صفحه عملکردهای مسدود کردن کنسول 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 در برنامه شما نیستند جلوگیری کنید:

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}"`);
  }
});

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

مثال زیر نشان می‌دهد که چگونه از ثبت نام کاربرانی که ایمیل‌های تایید نشده در برنامه خود دارند جلوگیری کنید:

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (user.email && !user.emailVerified) {
    throw new functions.auth.HttpsError(
      'invalid-argument', `Unverified email "${user.email}"`);
  }
});

نیاز به تایید ایمیل در ثبت نام

مثال زیر نشان می‌دهد که چگونه از کاربر بخواهیم ایمیل خود را پس از ثبت نام تأیید کند:

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.`);
  }
});

بررسی ایمیل‌های ارائه‌دهنده هویت خاص به عنوان تأیید شده

مثال زیر نشان می دهد که چگونه می توان با ایمیل های کاربر از ارائه دهندگان هویت خاص به عنوان تأیید شده برخورد کرد:

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (user.email && !user.emailVerified && context.eventType.indexOf(':facebook.com') !== -1) {
    return {
      emailVerified: true,
    };
  }
});

مسدود کردن ورود به سیستم از آدرس‌های IP خاص

مثال زیر نحوه مسدود کردن ورود به سیستم از محدوده آدرس IP خاص:

exports.beforeSignIn = functions.auth.user().beforeSignIn((user, context) => {
  if (isSuspiciousIpAddress(context.ipAddress)) {
    throw new functions.auth.HttpsError(
      'permission-denied', 'Unauthorized access!');
  }
});

تنظیم ادعاهای سفارشی و جلسه

مثال زیر نحوه تنظیم ادعاهای سفارشی و جلسات را نشان می دهد:

exports.beforeCreate = functions.auth.user().beforeCreate((user, context) => {
  if (context.credential &&
      context.credential.providerId === 'saml.my-provider-id') {
    return {
      // Employee ID does not change so save in persistent claims (stored in
      // Auth DB).
      customClaims: {
        eid: context.credential.claims.employeeid,
      },
      // Copy role and groups to token claims. These will not be persisted.
      sessionClaims: {
        role: context.credential.claims.role,
        groups: context.credential.claims.groups,
      }
    }
  }
});

ردیابی آدرس های IP برای نظارت بر فعالیت های مشکوک

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

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

   Node.js

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

2. هنگامی که کاربر سعی می کند با Firebase Authentication به منابعی دسترسی پیدا کند که نیاز به احراز هویت دارند، آدرس IP موجود در درخواست را با IP مورد استفاده برای ورود مقایسه کنید:

   Node.js

   app.post('/getRestrictedData', (req, res) => {
     // Get the ID token passed.
     const idToken = req.body.idToken;
     // Verify the ID token, check if revoked and decode its payload.
     admin.auth().verifyIdToken(idToken, true).then((claims) => {
       // Get request IP address
       const requestIpAddress = req.connection.remoteAddress;
       // Get sign-in IP address.
       const signInIpAddress = claims.signInIpAddress;
       // Check if the request IP address origin is suspicious relative to
       // the session IP addresses. The current request timestamp and the
       // auth_time of the ID token can provide additional signals of abuse,
       // especially if the IP address suddenly changed. If there was a sudden
       // geographical change in a short period of time, then it will give
       // stronger signals of possible abuse.
       if (!isSuspiciousIpAddressChange(signInIpAddress, requestIpAddress)) {
         // Suspicious IP address change. Require re-authentication.
         // You can also revoke all user sessions by calling:
         // admin.auth().revokeRefreshTokens(claims.sub).
         res.status(401).send({error: 'Unauthorized access. Please login again!'});
       } else {
         // Access is valid. Try to return data.
         getData(claims).then(data => {
           res.end(JSON.stringify(data);
         }, error => {
           res.status(500).send({ error: 'Server error!' })
         });
       }
     });
   });
   

غربالگری عکس های کاربران

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

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 استفاده کرد. نشانه رفرش برای دسترسی آفلاین ذخیره می شود.

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 را نادیده گرفت.

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',
 }
});