अनुमति वाले ब्लॉक करने वाले ट्रिगर

2nd gen 1st gen

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

ध्यान दें: ब्लॉक करने से जुड़े फ़ंक्शन का इस्तेमाल सिर्फ़ Firebase और Firebase CLI के साथ किया जा सकता है. ये Google Cloud Identity Platform के साथ काम नहीं करते.

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

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

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

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

• beforeCreate: यह ट्रिगर, नए उपयोगकर्ता को Firebase Authentication डेटाबेस में सेव करने से पहले और आपके क्लाइंट ऐप्लिकेशन को टोकन वापस भेजने से पहले ट्रिगर होता है.

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

• beforeEmail (सिर्फ़ Node.js के लिए): यह ट्रिगर, किसी उपयोगकर्ता को ईमेल (उदाहरण के लिए,
  साइन-इन या पासवर्ड रीसेट करने का ईमेल) भेजे जाने से पहले ट्रिगर होता है.

• beforeSms (सिर्फ़ Node.js के लिए): यह इवेंट, उपयोगकर्ता को एसएमएस भेजने से पहले ट्रिगर होता है. जैसे, मल्टीफ़ैक्टर ऑथेंटिकेशन के मामलों में.

ब्लॉक करने की सुविधाओं का इस्तेमाल करते समय, इन बातों का ध्यान रखें:

• आपके फ़ंक्शन को सात सेकंड के अंदर जवाब देना होगा. सात सेकंड बाद, Firebase Authentication गड़बड़ी का मैसेज दिखाता है और क्लाइंट का ऑपरेशन पूरा नहीं होता.

• 200 के अलावा अन्य एचटीटीपी रिस्पॉन्स कोड, आपके क्लाइंट ऐप्लिकेशन को पास किए जाते हैं. पक्का करें कि आपका क्लाइंट कोड, आपके फ़ंक्शन से मिलने वाली किसी भी गड़बड़ी को ठीक कर सके.

• फ़ंक्शन, आपके प्रोजेक्ट के सभी उपयोगकर्ताओं पर लागू होते हैं. इनमें किरायेदार के तौर पर शामिल उपयोगकर्ता भी शामिल हैं. Firebase Authentication आपके फ़ंक्शन को उपयोगकर्ताओं के बारे में जानकारी देता है. इसमें यह जानकारी भी शामिल होती है कि वे किस किरायेदार से जुड़े हैं, ताकि आप उसके हिसाब से जवाब दे सकें.

• किसी खाते से किसी अन्य आइडेंटिटी प्रोवाइडर को लिंक करने पर, रजिस्टर किए गए सभी beforeSignIn फ़ंक्शन फिर से ट्रिगर हो जाते हैं.

• गुमनाम और कस्टम पुष्टि करने से, ब्लॉक करने वाले फ़ंक्शन ट्रिगर नहीं होते.

चेतावनी: अगर आपने किसी फ़ंक्शन को मिटा दिया है, तो आपको Firebase Authentication के साथ ट्रिगर को भी अनरजिस्टर करना होगा. ऐसा न करने पर, सभी उपयोगकर्ता आपके ऐप्लिकेशन से पुष्टि नहीं कर पाएंगे.

ब्लॉक करने वाले फ़ंक्शन को डिप्लॉय करना

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

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

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

   उदाहरण के लिए, शुरू करने के लिए, 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 एपीआई का रेफ़रंस देखें.

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

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

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

JavaScript

// Blocking functions can also be triggered in a multi-tenant context before user creation.
// firebase.auth().tenantId = 'tenant-id-1';
firebase.auth().createUserWithEmailAndPassword('[e-mail]', '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 ऑब्जेक्ट में बदलाव किया जा सकता है. यह ऑब्जेक्ट, 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, दोनों के लिए इवेंट हैंडलर रजिस्टर किया है, तो ध्यान दें कि beforeCreate के बाद beforeSignIn काम करता है. 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 सेवा देने वाली कंपनी के साथ साइन इन करता है, तो ये क्रेडेंशियल पास किए जाएंगे:

• आईडी टोकन: यह तब दिया जाता है, जब 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

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

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

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

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

   Node.js

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

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

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