क्लाउड फ़ंक्शंस को अवरुद्ध करके फायरबेस प्रमाणीकरण बढ़ाएँ

ब्लॉकिंग फ़ंक्शंस आपको कस्टम कोड निष्पादित करने देता है जो आपके ऐप में पंजीकरण या साइन इन करने वाले उपयोगकर्ता के परिणाम को संशोधित करता है। उदाहरण के लिए, यदि उपयोगकर्ता कुछ मानदंडों को पूरा नहीं करता है, तो आप उसे प्रमाणित करने से रोक सकते हैं, या उपयोगकर्ता की जानकारी को अपने क्लाइंट ऐप पर वापस करने से पहले अपडेट कर सकते हैं।

शुरू करने से पहले

अवरोधक कार्यों का उपयोग करने के लिए आपको अपने फायरबेस प्रोजेक्ट को आइडेंटिटी प्लेटफॉर्म के साथ फायरबेस ऑथेंटिकेशन में अपग्रेड करना होगा। यदि आपने पहले से अपग्रेड नहीं किया है, तो पहले ऐसा करें।

अवरोधक कार्यों को समझना

आप दो घटनाओं के लिए अवरोधक कार्यों को पंजीकृत कर सकते हैं:

• beforeCreate : एक नए उपयोगकर्ता को फायरबेस प्रमाणीकरण डेटाबेस में सहेजे जाने से पहले और आपके क्लाइंट ऐप पर टोकन वापस आने से पहले ट्रिगर करता है।

• beforeSignIn : उपयोगकर्ता के क्रेडेंशियल सत्यापित होने के बाद ट्रिगर, लेकिन फायरबेस प्रमाणीकरण से पहले आपके क्लाइंट ऐप पर एक आईडी टोकन लौटाता है। यदि आपका ऐप मल्टी-फैक्टर ऑथेंटिकेशन का उपयोग करता है, तो उपयोगकर्ता द्वारा उनके दूसरे फैक्टर को सत्यापित करने के बाद फ़ंक्शन ट्रिगर हो जाता है। ध्यान दें कि एक नया उपयोगकर्ता बनाना भी beforeSignIn के अलावा, beforeCreate को भी ट्रिगर करता है।

ब्लॉकिंग फ़ंक्शंस का उपयोग करते समय निम्नलिखित बातों का ध्यान रखें:

• आपके कार्य को 7 सेकंड के भीतर जवाब देना चाहिए। 7 सेकंड के बाद, फायरबेस ऑथेंटिकेशन एक त्रुटि देता है, और क्लाइंट ऑपरेशन विफल हो जाता है।

• 200 के अलावा अन्य HTTP प्रतिक्रिया कोड आपके क्लाइंट ऐप्स को पास किए जाते हैं। सुनिश्चित करें कि आपका क्लाइंट कोड ऐसी किसी भी त्रुटि को संभालता है जिसे आपका फ़ंक्शन वापस कर सकता है।

• प्रकार्य आपके प्रोजेक्ट के सभी उपयोगकर्ताओं पर लागू होते हैं, जिसमें किरायेदार में निहित कोई भी शामिल है। फायरबेस ऑथेंटिकेशन आपके फ़ंक्शन के उपयोगकर्ताओं के बारे में जानकारी प्रदान करता है, जिसमें वे किसी भी किरायेदार से संबंधित हैं, ताकि आप तदनुसार जवाब दे सकें।

• किसी अन्य पहचान प्रदाता को किसी खाते से लिंक करना किसी भी पंजीकृत beforeSignIn कार्यों को फिर से ट्रिगर करता है।

• बेनामी और कस्टम प्रमाणीकरण ब्लॉकिंग फ़ंक्शंस को ट्रिगर नहीं करते हैं।

एक अवरोधक कार्य को तैनात और पंजीकृत करें

उपयोगकर्ता प्रमाणीकरण प्रवाह में अपना कस्टम कोड सम्मिलित करने के लिए, अवरोधक कार्यों को परिनियोजित और पंजीकृत करें। एक बार जब आपके ब्लॉकिंग फ़ंक्शन तैनात और पंजीकृत हो जाते हैं, तो प्रमाणीकरण और उपयोगकर्ता निर्माण सफल होने के लिए आपका कस्टम कोड सफलतापूर्वक पूरा होना चाहिए।

एक अवरोधक समारोह तैनात करें

आप एक ब्लॉकिंग फ़ंक्शन को उसी तरह परिनियोजित करते हैं जैसे आप किसी फ़ंक्शन को परिनियोजित करते हैं। (विवरण के लिए क्लाउड फ़ंक्शंस प्रारंभ करना पृष्ठ देखें)। सारांश:

1. क्लाउड फ़ंक्शंस लिखें जो beforeCreate इवेंट, beforeSignIn इवेंट, या दोनों को संभालते हैं।

   उदाहरण के लिए, आरंभ करने के लिए, आप निम्नलिखित नो-ऑप फ़ंक्शंस को 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
   

   हर बार जब आप उन्हें अपडेट करते हैं तो आपको अपने कार्यों को फिर से तैनात करना होगा।

एक अवरोधक समारोह पंजीकृत करें

1. फायरबेस कंसोल में फायरबेस ऑथेंटिकेशन सेटिंग्स पेज पर जाएं।

2. ब्लॉकिंग फ़ंक्शंस टैब चुनें।

3. खाता बनाने से पहले (क्रिएट करने से पहले) या साइन इन करने से पहले (साइन इन करने से पहले) के तहत ड्रॉपडाउन मेनू से इसे चुनकर अपने ब्लॉकिंग फ़ंक्शन को पंजीकृत करें।

4. अपने परिवर्तन सहेजें।

उपयोगकर्ता और संदर्भ जानकारी प्राप्त करना

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

भले ही आप एक डिफ़ॉल्ट या कस्टम संदेश का उपयोग करें, क्लाउड फ़ंक्शंस त्रुटि को लपेटता है और क्लाइंट को आंतरिक त्रुटि के रूप में लौटाता है। उदाहरण के लिए:

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 ऑब्जेक्ट को संशोधित करें और क्लाइंट को लौटा दें।

किसी उपयोगकर्ता को संशोधित करने के लिए, संशोधित करने के लिए फ़ील्ड वाले अपने ईवेंट हैंडलर से ऑब्जेक्ट वापस करें। आप निम्नलिखित क्षेत्रों को संशोधित कर सकते हैं:

• displayName
• disabled
• emailVerified
• photoURL
• customClaims
• sessionClaims (केवल beforeSignIn )

sessionClaims के अपवाद के साथ, सभी संशोधित फ़ील्ड फायरबेस ऑथेंटिकेशन के डेटाबेस में सहेजे जाते हैं, जिसका अर्थ है कि वे प्रतिक्रिया टोकन में शामिल हैं और उपयोगकर्ता सत्रों के बीच बने रहते हैं।

निम्न उदाहरण दिखाता है कि डिफ़ॉल्ट प्रदर्शन नाम कैसे सेट करें:

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 प्रमाण-पत्र और डेटा पास कर सकते हैं। निम्न तालिका दर्शाती है कि प्रत्येक पहचान प्रदाता के लिए कौन से क्रेडेंशियल्स और डेटा समर्थित हैं:

टोकन ताज़ा करें

ब्लॉकिंग फंक्शन में रिफ्रेश टोकन का उपयोग करने के लिए, आपको पहले फायरबेस कंसोल के ब्लॉकिंग फंक्शन पेज पर चेकबॉक्स का चयन करना होगा।

किसी OAuth क्रेडेंशियल, जैसे ID टोकन या एक्सेस टोकन के साथ सीधे साइन इन करने पर कोई भी पहचान प्रदाता रीफ़्रेश टोकन वापस नहीं करेगा। इस स्थिति में, वही क्लाइंट-साइड OAuth क्रेडेंशियल ब्लॉकिंग फ़ंक्शन को पास किया जाएगा।

निम्नलिखित खंड प्रत्येक पहचान प्रदाता प्रकार और उनके समर्थित क्रेडेंशियल्स और डेटा का वर्णन करते हैं।

सामान्य OIDC प्रदाता

जब कोई उपयोगकर्ता एक सामान्य ओआईडीसी प्रदाता के साथ साइन इन करता है, तो निम्नलिखित क्रेडेंशियल पास किए जाएंगे:

• आईडी टोकन : बशर्ते कि id_token प्रवाह का चयन किया गया हो।
• पहुँच टोकन : बशर्ते कि कोड प्रवाह का चयन किया गया हो। ध्यान दें कि कोड प्रवाह वर्तमान में केवल REST API द्वारा समर्थित है।
• रीफ्रेश टोकन : बशर्ते अगर offline_access स्कोप चुना गया हो।

उदाहरण:

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

गूगल

जब कोई उपयोगकर्ता Google के साथ साइन इन करता है, तो निम्नलिखित क्रेडेंशियल पास किए जाएंगे:

• आईडी टोकन
• एक्सेस टोकन
• रीफ्रेश टोकन : केवल तभी प्रदान किया जाता है जब निम्नलिखित कस्टम पैरामीटर का अनुरोध किया जाता है:
  • access_type=offline
  • prompt=consent , अगर उपयोगकर्ता ने पहले सहमति दी थी और किसी नए दायरे का अनुरोध नहीं किया गया था

उदाहरण:

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

Google रीफ्रेश टोकन के बारे में और जानें।

फेसबुक

जब कोई उपयोगकर्ता Facebook के साथ साइन इन करता है, तो निम्न क्रेडेंशियल पारित किया जाएगा:

• एक्सेस टोकन : एक एक्सेस टोकन वापस किया जाता है जिसे दूसरे एक्सेस टोकन के लिए एक्सचेंज किया जा सकता है। फेसबुक द्वारा समर्थित विभिन्न प्रकार के एक्सेस टोकन के बारे में और जानें कि आप उन्हें लंबे समय तक रहने वाले टोकन के लिए कैसे एक्सचेंज कर सकते हैं।

GitHub

जब कोई उपयोगकर्ता GitHub के साथ साइन इन करता है, तो निम्न क्रेडेंशियल पारित किया जाएगा:

• एक्सेस टोकन : रद्द किए जाने तक समाप्त नहीं होता है।

माइक्रोसॉफ्ट

जब कोई उपयोगकर्ता Microsoft के साथ साइन इन करता है, तो निम्नलिखित क्रेडेंशियल पास किए जाएंगे:

• आईडी टोकन
• एक्सेस टोकन
• रीफ्रेश टोकन : यदि offline_access स्कोप चुना गया है तो ब्लॉकिंग फ़ंक्शन को पास किया गया।

उदाहरण:

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

याहू

जब कोई उपयोगकर्ता याहू के साथ साइन इन करता है, तो निम्नलिखित क्रेडेंशियल बिना किसी कस्टम पैरामीटर या स्कोप के पारित किए जाएंगे:

• आईडी टोकन
• एक्सेस टोकन
• रीफ्रेश टोकन

Linkedin

जब कोई उपयोगकर्ता लिंक्डइन के साथ साइन इन करता है, तो निम्न क्रेडेंशियल पारित किया जाएगा:

• एक्सेस टोकन

सेब

जब कोई उपयोगकर्ता Apple के साथ साइन इन करता है, तो निम्नलिखित क्रेडेंशियल बिना किसी कस्टम पैरामीटर या दायरे के पारित किए जाएंगे:

• आईडी टोकन
• एक्सेस टोकन
• रीफ्रेश टोकन

सामान्य परिदृश्य

निम्नलिखित उदाहरण कार्यों को अवरुद्ध करने के लिए कुछ सामान्य उपयोग के मामलों को प्रदर्शित करते हैं:

केवल एक विशिष्ट डोमेन से पंजीकरण की अनुमति देना

निम्न उदाहरण दिखाता है कि उन उपयोगकर्ताओं को कैसे रोका जाए जो 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 विभिन्न भौगोलिक क्षेत्रों से हैं — तो आप उपयोगकर्ता को फिर से साइन इन करने के लिए कह सकते हैं।

1. उपयोगकर्ता द्वारा साइन इन किए गए IP पते को ट्रैक करने के लिए सत्र दावों का उपयोग करें:

   नोड.जेएस

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

2. जब कोई उपयोगकर्ता फायरबेस प्रमाणीकरण के साथ प्रमाणीकरण की आवश्यकता वाले संसाधनों तक पहुंचने का प्रयास करता है, तो साइन इन करने के लिए उपयोग किए गए आईपी के साथ अनुरोध में आईपी पते की तुलना करें:

   नोड.जेएस

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

छवियों का पता लगाने और उन्हें साफ करने के तरीके के बारे में अधिक जानने के लिए, क्लाउड विज़न दस्तावेज़ीकरण देखें।

उपयोगकर्ता के पहचान प्रदाता OAuth क्रेडेंशियल्स को एक्सेस करना

निम्न उदाहरण दर्शाता है कि Google के साथ साइन इन करने वाले उपयोगकर्ता के लिए रीफ्रेश टोकन कैसे प्राप्त करें, और Google कैलेंडर API को कॉल करने के लिए इसका उपयोग कैसे करें। रीफ्रेश टोकन ऑफ़लाइन पहुंच के लिए संग्रहीत किया जाता है।

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();
          });
      });
    })
  }
});