Firebase से पुष्टि करने वाले ट्रिगर

Firebase Authentication उपयोगकर्ता खातों के बनने और मिटने पर, फ़ंक्शन ट्रिगर किए जा सकते हैं. उदाहरण के लिए, आपके पास ऐसे उपयोगकर्ता को वेलकम ईमेल भेजने का विकल्प होता है जिसने अभी-अभी आपके ऐप्लिकेशन में खाता बनाया है. इस पेज पर दिए गए उदाहरण, एक ऐसे सैंपल पर आधारित हैं जो ठीक यही काम करता है. यानी, खाता बनाने और मिटाने पर वेलकम और फ़ेयरवेल ईमेल भेजता है.

इस्तेमाल के उदाहरणों के बारे में ज़्यादा जानने के लिए, Cloud Functions का इस्तेमाल किस तरह किया जा सकता है? लेख पढ़ें.

उपयोगकर्ता खाता बनाए जाने पर किसी फ़ंक्शन को ट्रिगर करना

ऐसा फ़ंक्शन बनाया जा सकता है जो Authentication उपयोगकर्ता के लिए तब ट्रिगर होता है, जब उसे firebase-functions/v2/identity सबपैकेज के onUserCreated इवेंट हैंडलर का इस्तेमाल करके बनाया जाता है:

const { onUserCreated } = require("firebase-functions/identity");
const { defineSecret } = require("firebase-functions/params");
const { logger } = require("firebase-functions");
const { sendWelcomeEmail } = require("./utils/myEmailService");

const emailApiKey = defineSecret("EMAIL_API_KEY");

exports.newUserWelcome = onUserCreated(
  { secrets: [emailApiKey] },
  async (event) => {
    const { uid, email, displayName } = event.data;

    if (!email) {
      logger.log(`User ${uid} does not have an email address.`);
      return;
    }

    await sendWelcomeEmail(email, displayName);
  },
);

Authentication खातों से, Cloud Functions के लिए उपयोगकर्ता बनाने वाले इवेंट ट्रिगर होंगे. ऐसा तब होगा, जब:

  • कोई उपयोगकर्ता ईमेल खाता और पासवर्ड बनाता है.
  • जब कोई उपयोगकर्ता फ़ेडरेटेड आइडेंटिटी प्रोवाइडर का इस्तेमाल करके पहली बार साइन इन करता है.
  • डेवलपर, Admin SDK का इस्तेमाल करके खाता बनाता है.
  • जब कोई उपयोगकर्ता पहली बार, अनाम पुष्टि वाले नए सेशन में साइन इन करता है.

जब कोई उपयोगकर्ता कस्टम टोकन का इस्तेमाल करके पहली बार साइन इन करता है, तब Cloud Functions इवेंट ट्रिगर नहीं होता है.

ट्रिगर के विकल्प और मल्टी-टेंसी कॉन्फ़िगर करना

onUserCreated फ़ंक्शन के पहले पैरामीटर के तौर पर, विकल्प ऑब्जेक्ट (AuthOptions) पास करके अपने फ़ंक्शन को कॉन्फ़िगर किया जा सकता है:

/**
 * Sends a welcome email scoped to a specific tenant in Identity Platform.
 */
exports.sendWelcomeEmailToTenant = onUserCreated(
  {
    secrets: [emailApiKey],
    // Only trigger when a user is a member of this tenant
    tenantId: "my-tenant-id",
  },
  async (event) => {
    const { uid, email, displayName } = event.data;
    // Customize the email for this tenant
    await sendWelcomeEmail(email, displayName, event.tenantId);
  },
);
  /**
 * Sends a welcome email only to users not associated with any tenant.
 */
exports.sendWelcomeEmailNoTenant = onUserCreated(
  {
    secrets: [emailApiKey],
    // Only trigger when a user is NOT a member of a tenant
    tenantId: IS_NOT_TENANT,
  },
  async (event) => {
    const { email, displayName } = event.data;

    // Send a generic welcome email
    await sendWelcomeEmail(email, displayName);
  },
);

अगर आपका प्रोजेक्ट Identity Platform की मल्टी-टेनेंसी का इस्तेमाल करता है, तो ट्रिगर को स्कोप किया जा सकता है:

  • डिफ़ॉल्ट प्रोजेक्ट (कोई किरायेदार नहीं): सिर्फ़ डिफ़ॉल्ट प्रोजेक्ट में बनाए गए उपयोगकर्ताओं के लिए सुनने के लिए, tenantId को IS_NOT_TENANT पर सेट करें.
  • खास किरायेदार: सिर्फ़ उस किरायेदार के लिए बनाए गए उपयोगकर्ताओं की जानकारी पाने के लिए, किरायेदार का स्ट्रिंग आईडी (उदाहरण के लिए, { tenantId: "tenant-id-1" }) दें.
  • सभी किरायेदार और उपयोगकर्ता: अगर tenantId को शामिल नहीं किया जाता है, तो यह फ़ंक्शन, सभी किरायेदार और प्रोजेक्ट के डिफ़ॉल्ट उपयोगकर्ताओं के लिए, उपयोगकर्ता बनाने के इवेंट पर ट्रिगर होता है.

tenantId के अलावा, स्टैंडर्ड 2nd gen कॉन्फ़िगरेशन के विकल्प भी तय किए जा सकते हैं. इनमें region, concurrency, cpu, memory, timeoutSeconds, minInstances, maxInstances, और secrets शामिल हैं.

उपयोगकर्ता के एट्रिब्यूट ऐक्सेस करना

आपके फ़ंक्शन को मिले उपयोगकर्ता का डेटा से, event.data के ज़रिए, नए उपयोगकर्ता के UserRecord ऑब्जेक्ट में मौजूद उपयोगकर्ता एट्रिब्यूट की सूची को ऐक्सेस किया जा सकता है. उदाहरण के लिए, उपयोगकर्ता का ईमेल और डिसप्ले नेम इस तरह से पाया जा सकता है:

const { uid, email, displayName } = event.data;

दूसरी जनरेशन के ऑथेंटिकेशन ट्रिगर को AuthEvent ऑब्जेक्ट मिलता है. event.data के अलावा, इवेंट के मेटाडेटा को भी ऐक्सेस किया जा सकता है. जैसे:

  • event.id: यह इवेंट के लिए यूनीक आइडेंटिफ़ायर होता है.
  • event.type: इवेंट का टाइप (google.firebase.auth.user.v2.created).
  • event.time: यह आईएसओ 8601 टाइमस्टैंप है. इससे पता चलता है कि इवेंट कब हुआ.
  • event.project: Google Cloud प्रोजेक्ट आईडी.
  • event.tenantId: अगर लागू हो, तो उपयोगकर्ता से जुड़ा Identity Platform का किरायेदार आईडी.

उपयोगकर्ता का खाता मिटाने पर किसी फ़ंक्शन को ट्रिगर करना

उपयोगकर्ता के खाते के बनने पर किसी फ़ंक्शन को ट्रिगर किया जा सकता है. इसी तरह, उपयोगकर्ता के खाते के मिटने पर होने वाले इवेंट पर प्रतिक्रिया दी जा सकती है. firebase-functions/v2/identity से onUserDeleted इवेंट हैंडलर का इस्तेमाल करें. इसे यहां दिखाया गया है:

const { onUserDeleted } = require("firebase-functions/identity");
const { defineSecret } = require("firebase-functions/params");
const { logger } = require("firebase-functions");
const { sendGoodbyeEmail } = require("./utils/myEmailService");

const emailApiKey = defineSecret("EMAIL_API_KEY");

exports.deletedUserFarewell = onUserDeleted(
  { secrets: [emailApiKey] },
  async (event) => {
    const { uid, email, displayName } = event.data;
    if (!email) {
      logger.log(`User ${uid} does not have an email address.`);
      return;
    }

    await sendGoodbyeEmail(email, displayName);
  },
);

onUserCreated की तरह, onUserDeleted को भी कॉन्फ़िगर किया जा सकता है. इसके लिए, { tenantId: IS_NOT_TENANT } जैसे विकल्पों का इस्तेमाल किया जा सकता है, ताकि ट्रिगर को डिफ़ॉल्ट प्रोजेक्ट के उपयोगकर्ताओं के लिए सीमित किया जा सके.

ट्रिगर ब्लॉक करने वाले फ़ंक्शन

अगर आपने Firebase Authentication with Identity Platform पर अपग्रेड किया है, तो ब्लॉक करने से जुड़े फ़ंक्शन का इस्तेमाल करके, Firebase Authentication को बढ़ाया जा सकता है.

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

दूसरी जनरेशन के ट्रिगर के लिए सबसे सही तरीके

दूसरी जनरेशन के पुष्टि करने वाले ट्रिगर लागू करते समय, इन सबसे सही तरीकों को ध्यान में रखें:

  • एक साथ कई अनुरोधों को प्रोसेस करने की सुविधा: Cloud Functions (2nd gen) के इंस्टेंस, एक साथ कई अनुरोधों को प्रोसेस करते हैं. सीपीयू ≥ 1 होने पर, डिफ़ॉल्ट रूप से एक साथ 80 अनुरोधों को प्रोसेस किया जाता है. पक्का करें कि आपका फ़ंक्शन, एक साथ कई बार चलने पर ग्लोबल म्यूटबल स्टेट पर निर्भर न हो.
  • आइडेंटपोटेंसी के लिए डिज़ाइन करें: दूसरी जनरेशन में इवेंट डिलीवरी, Eventarc के ज़रिए कम से कम एक बार होती है. पक्का करें कि आपके फ़ंक्शन, आइडेमपोटेंट हों. उदाहरण के लिए, पुष्टि करें कि साइड इफ़ेक्ट लागू करने से पहले, स्वागत वाला ईमेल पहले ही न भेजा गया हो या डेटाबेस एंट्री शुरू न की गई हो.
  • मल्टी-टेनेंट फ़ंक्शन का दायरा तय करना: अगर आपका ऐप्लिकेशन Identity Platform के मल्टी-टेनेंसी फ़ंक्शन का इस्तेमाल करता है, तो पुष्टि करें कि आपके फ़ंक्शन को सभी टेनेंट के इवेंट हैंडल करने चाहिए या सिर्फ़ कुछ खास टेनेंट के. tenantId: IS_NOT_TENANT का इस्तेमाल करके, किरायेदार के उपयोगकर्ताओं को उन फ़ंक्शन को ट्रिगर करने से रोकें जो सिर्फ़ प्राइमरी प्रोजेक्ट के लिए हैं.
  • रीजन और संसाधन के बंटवारे को मैनेज करना: फ़ंक्शन की जगह (region) तय करें, ताकि पुष्टि करने वाली सेवा और फ़ंक्शन को लागू करने वाले एनवायरमेंट के बीच नेटवर्क की लेटेन्सी कम हो.