在 2024 年演示日活动中，观看有关如何使用 Firebase 构建和运行 AI 赋能应用的演示。立即观看。

इस पेज का अनुवाद Cloud Translation API से किया गया है.

ब्लॉक करने वाले फ़ंक्शन की मदद से, Firebase से पुष्टि करने की सुविधा को बेहतर बनाएं

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

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

ब्लॉक करने की सुविधाओं का इस्तेमाल करने के लिए, आपको अपने Firebase प्रोजेक्ट को Firebase Authentication with Identity Platform पर अपग्रेड करना होगा. अगर आपने अब तक अपग्रेड नहीं किया है, तो सबसे पहले ऐसा करें.

ब्लॉक करने की सुविधाओं को समझना

इन इवेंट के लिए, ब्लॉक करने की सुविधाएं रजिस्टर की जा सकती हैं:

beforeCreate: यह ट्रिगर तब होता है, जब किसी नए उपयोगकर्ता को Firebase Authentication डेटाबेस में सेव किया जाता है और आपके क्लाइंट ऐप्लिकेशन को टोकन वापस किया जाता है.
beforeSignIn: उपयोगकर्ता के क्रेडेंशियल की पुष्टि होने के बाद, लेकिन Firebase Authentication के आपके क्लाइंट ऐप्लिकेशन को आईडी टोकन दिखाने से पहले ट्रिगर होता है. अगर आपका ऐप्लिकेशन, कई तरीकों से पुष्टि करने की सुविधा का इस्तेमाल करता है, तो उपयोगकर्ता के दूसरे तरीके से पुष्टि करने के बाद फ़ंक्शन ट्रिगर होता है. ध्यान दें कि नया उपयोगकर्ता बनाने पर, beforeCreate के साथ-साथ beforeSignIn भी ट्रिगर होता है.
beforeEmail (सिर्फ़ Node.js के लिए): उपयोगकर्ता को कोई ईमेल भेजे जाने से पहले ट्रिगर होता है. उदाहरण के लिए,
साइन इन या पासवर्ड रीसेट करने का ईमेल.
beforeSms (सिर्फ़ Node.js के लिए): उपयोगकर्ता को एसएमएस मैसेज भेजने से पहले ट्रिगर होता है. ऐसा, कई तरीकों से पुष्टि करने जैसे मामलों में होता है.

ब्लॉक करने वाले फ़ंक्शन का इस्तेमाल करते समय, इन बातों का ध्यान रखें:

आपका फ़ंक्शन सात सेकंड के अंदर जवाब देना चाहिए. सात सेकंड बाद, Firebase Authentication गड़बड़ी का मैसेज दिखाता है और क्लाइंट ऑपरेशन पूरा नहीं हो पाता.
200 के अलावा, अन्य एचटीटीपी रिस्पॉन्स कोड आपके क्लाइंट ऐप्लिकेशन को भेजे जाते हैं. पक्का करें कि आपका क्लाइंट कोड, उन सभी गड़बड़ियों को मैनेज करता हो जो आपके फ़ंक्शन से हो सकती हैं.
फ़ंक्शन, आपके प्रोजेक्ट के सभी उपयोगकर्ताओं पर लागू होते हैं. इनमें टेंंट में मौजूद उपयोगकर्ता भी शामिल हैं. Firebase Authentication आपके फ़ंक्शन के लिए उपयोगकर्ताओं की जानकारी उपलब्ध कराता है. इसमें, उनसे जुड़े सभी किरायेदारों की जानकारी भी शामिल होती है, ताकि आप उनसे जुड़े सवालों के हिसाब से जवाब दे सकें.
किसी खाते से किसी अन्य आइडेंटिटी प्रोवाइडर को लिंक करने पर, रजिस्टर किए गए सभी beforeSignIn फ़ंक्शन फिर से ट्रिगर हो जाते हैं.
बिना पहचान ज़ाहिर किए और कस्टम तरीके से पुष्टि करने पर, ब्लॉक करने की सुविधाएं ट्रिगर नहीं होतीं.

ब्लॉक करने की सुविधा को डिप्लॉय करना

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

ब्लॉकिंग फ़ंक्शन को उसी तरह से डिप्लॉय किया जाता है जिस तरह से किसी भी फ़ंक्शन को डिप्लॉय किया जाता है. ज़्यादा जानकारी के लिए, Cloud Functions शुरू करना पेज पर जाएं. सारांश में:

टारगेट किए गए इवेंट को मैनेज करने वाला फ़ंक्शन लिखें.

उदाहरण के लिए, शुरू करने के लिए, 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 सीएलआई का इस्तेमाल करके, अपने फ़ंक्शन डिप्लॉय करें:
```
firebase deploy --only functions
```
फ़ंक्शन को हर बार अपडेट करने पर, आपको उन्हें फिर से डिप्लॉय करना होगा.

उपयोगकर्ता और कॉन्टेक्स्ट की जानकारी पाना

beforeSignIn और beforeCreate इवेंट, User और EventContext ऑब्जेक्ट उपलब्ध कराते हैं. इनमें, साइन इन करने वाले उपयोगकर्ता की जानकारी होती है. अपने कोड में इन वैल्यू का इस्तेमाल करके, यह तय करें कि किसी कार्रवाई को जारी रखने की अनुमति देनी है या नहीं.

User ऑब्जेक्ट पर उपलब्ध प्रॉपर्टी की सूची के लिए, UserRecord एपीआई का रेफ़रंस देखें.

EventContext ऑब्जेक्ट में ये प्रॉपर्टी शामिल होती हैं:

नाम	ब्यौरा	उदाहरण
`locale`	ऐप्लिकेशन की स्थान-भाषा. क्लाइंट SDK का इस्तेमाल करके या REST API में locale हेडर पास करके, भाषा सेट की जा सकती है.	`fr` या `sv-SE`
`ipAddress`	उस डिवाइस का आईपी पता जिससे असली उपयोगकर्ता रजिस्टर कर रहा है या साइन इन कर रहा है.	`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`	इवेंट ट्रिगर होने का समय, आरएफ़सी 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`	सर्वर ने एपीआई तरीका लागू नहीं किया.
`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}`);

आपके ऐप्लिकेशन को गड़बड़ी का पता चलना चाहिए और उसे ठीक करना चाहिए. उदाहरण के लिए:

JavaScript

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

किसी उपयोगकर्ता की भूमिका में बदलाव करना

रजिस्टर करने या साइन इन करने की कोशिश को ब्लॉक करने के बजाय, आपके पास ऑपरेशन को जारी रखने का विकल्प है. हालांकि, Firebase Authentication के डेटाबेस में सेव किए गए और क्लाइंट को वापस भेजे गए User ऑब्जेक्ट में बदलाव किया जा सकता है.

किसी उपयोगकर्ता की जानकारी में बदलाव करने के लिए, अपने इवेंट हैंडलर से ऐसा ऑब्जेक्ट दिखाएं जिसमें बदलाव करने के लिए फ़ील्ड शामिल हों. इन फ़ील्ड में बदलाव किया जा सकता है:

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 क्रेडेंशियल और डेटा पास किया जा सकता है. इस टेबल में बताया गया है कि पहचान की पुष्टि करने वाली हर सेवा के लिए कौनसे क्रेडेंशियल और डेटा इस्तेमाल किए जा सकते हैं:

पहचान देने वाली सेवा	आईडी टोकन	ऐक्सेस टोकन	समाप्ति‍ समय	टोकन सीक्रेट	रीफ़्रेश टोकन	साइन-इन करने से जुड़े दावे
Google	हां	हां	हां	नहीं	हां	नहीं
Facebook	नहीं	हां	हां	नहीं	नहीं	नहीं
Twitter	नहीं	हां	नहीं	हां	नहीं	नहीं
GitHub	नहीं	हां	नहीं	नहीं	नहीं	नहीं
Microsoft	हां	हां	हां	नहीं	हां	नहीं
LinkedIn	नहीं	हां	हां	नहीं	नहीं	नहीं
Yahoo	हां	हां	हां	नहीं	हां	नहीं
Apple	हां	हां	हां	नहीं	हां	नहीं
एसएएमएल	नहीं	नहीं	नहीं	नहीं	नहीं	हां
OIDC	हां	हां	हां	नहीं	हां	हां

रीफ़्रेश टोकन

ब्लॉकिंग फ़ंक्शन में रीफ़्रेश टोकन का इस्तेमाल करने के लिए, आपको सबसे पहले Firebase कंसोल के ब्लॉकिंग फ़ंक्शन पेज पर मौजूद चेकबॉक्स चुनना होगा.

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

नीचे दिए गए सेक्शन में, पहचान की पुष्टि करने वाली सेवा देने वाली हर कंपनी के टाइप और उनके साथ काम करने वाले क्रेडेंशियल और डेटा के बारे में बताया गया है.

सामान्य OIDC प्रोवाइडर

जब कोई उपयोगकर्ता किसी सामान्य 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

जब कोई उपयोगकर्ता 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

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

ऐक्सेस टोकन: एक ऐक्सेस टोकन दिखाया जाता है, जिसे किसी दूसरे ऐक्सेस टोकन से बदला जा सकता है. Facebook के साथ काम करने वाले अलग-अलग तरह के ऐक्सेस टोकन के बारे में ज़्यादा जानें. साथ ही, यह भी जानें कि लंबे समय तक काम करने वाले टोकन के लिए, इन टोकन को कैसे बदला जा सकता है.

GitHub

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

ऐक्सेस टोकन: जब तक उसे रद्द नहीं किया जाता, तब तक उसकी समयसीमा खत्म नहीं होती.

Microsoft

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

आईडी टोकन
ऐक्सेस टोकन
रीफ़्रेश टोकन: अगर offline_access स्कोप चुना गया है, तो ब्लॉक करने वाले फ़ंक्शन को पास किया जाता है.

उदाहरण:

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

Yahoo

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

आईडी टोकन
ऐक्सेस टोकन
रीफ़्रेश टोकन

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

ऐक्सेस टोकन

Apple

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

आईडी टोकन
ऐक्सेस टोकन
रीफ़्रेश टोकन

आम तौर पर सामने आने वाली स्थितियां

यहां कुछ उदाहरणों की मदद से, ब्लॉक करने के फ़ंक्शन के सामान्य इस्तेमाल के बारे में बताया गया है:

सिर्फ़ किसी खास डोमेन से रजिस्ट्रेशन की अनुमति देना

यहां दिए गए उदाहरण में, 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,
    };
  }
});

कुछ आईपी पतों से साइन इन करने की सुविधा को ब्लॉक करना

यहां दिए गए उदाहरण में, कुछ आईपी पते की सीमाओं से साइन इन करने पर रोक लगाने का तरीका बताया गया है:

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

संदिग्ध गतिविधि पर नज़र रखने के लिए, आईपी पतों को ट्रैक करना

टोकन की चोरी को रोकने के लिए, उस आईपी पते को ट्रैक करें जिससे उपयोगकर्ता साइन इन करता है. साथ ही, बाद के अनुरोधों पर उस आईपी पते की तुलना करें. अगर अनुरोध संदिग्ध लगता है — उदाहरण के लिए, आईपी अलग-अलग भौगोलिक इलाकों से हैं — तो उपयोगकर्ता से फिर से साइन इन करने के लिए कहा जा सकता है.

सेशन के दावों का इस्तेमाल करके, उस आईपी पते को ट्रैक करें जिसका इस्तेमाल करके उपयोगकर्ता साइन इन करता है:

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

जब कोई उपयोगकर्ता ऐसे संसाधनों को ऐक्सेस करने की कोशिश करता है जिनके लिए Firebase Authentication की मदद से पुष्टि करना ज़रूरी है, तो अनुरोध में दिए गए आईपी पते की तुलना, साइन इन करने के लिए इस्तेमाल किए गए आईपी से करें:

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 से साइन इन करने वाले उपयोगकर्ता के लिए रीफ़्रेश टोकन पाने और Google Calendar के एपीआई को कॉल करने के लिए, उसका इस्तेमाल करने का तरीका बताया गया है. रीफ़्रेश टोकन को ऑफ़लाइन ऐक्सेस के लिए सेव किया जाता है.

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