ब्लॉकिंग फ़ंक्शंस के साथ फ़ायरबेस प्रमाणीकरण का विस्तार करें


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

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

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

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

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

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

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

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

  • आपके फ़ंक्शन को 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 deploy --only functions
    

    हर बार जब आप अपने कार्यों को अद्यतन करते हैं तो आपको उन्हें पुनः तैनात करना होगा।

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

beforeSignIn और beforeCreate ईवेंट User और EventContext ऑब्जेक्ट प्रदान करते हैं जिनमें साइन इन करने वाले उपयोगकर्ता के बारे में जानकारी होती है। किसी ऑपरेशन को आगे बढ़ने की अनुमति देनी है या नहीं यह निर्धारित करने के लिए अपने कोड में इन मानों का उपयोग करें।

User ऑब्जेक्ट पर उपलब्ध गुणों की सूची के लिए, UserRecord API संदर्भ देखें।

EventContext ऑब्जेक्ट में निम्नलिखित गुण हैं:

नाम विवरण उदाहरण
locale एप्लिकेशन स्थान. आप क्लाइंट SDK का उपयोग करके या 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 फायरबेस प्रमाणीकरण परियोजना या किरायेदार। projects/ project-id /tenants/ tenant-id
timestamp जिस समय ईवेंट ट्रिगर हुआ, उसे RFC 3339 स्ट्रिंग के रूप में स्वरूपित किया गया। Tue, 23 Jul 2019 21:10:57 GMT
additionalUserInfo एक वस्तु जिसमें उपयोगकर्ता के बारे में जानकारी होती है। AdditionalUserInfo
credential एक ऑब्जेक्ट जिसमें उपयोगकर्ता के क्रेडेंशियल के बारे में जानकारी होती है। AuthCredential

पंजीकरण या साइन-इन को अवरुद्ध करना

पंजीकरण या साइन-इन प्रयास को अवरुद्ध करने के लिए, अपने फ़ंक्शन में एक HttpsError डालें। उदाहरण के लिए:

नोड.जे.एस

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 अनुरोध की समय सीमा पार हो गई.

आप एक कस्टम त्रुटि संदेश भी निर्दिष्ट कर सकते हैं:

नोड.जे.एस

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

पहचान प्रदाता आईडी टोकन एक्सेस टोकन समय सीमा समाप्ति समय सांकेतिक रहस्य टोकन ताज़ा करें साइन-इन दावे
गूगल हाँ हाँ हाँ नहीं हाँ नहीं
फेसबुक नहीं हाँ हाँ नहीं नहीं नहीं
ट्विटर नहीं हाँ नहीं हाँ नहीं नहीं
GitHub नहीं हाँ नहीं नहीं नहीं नहीं
माइक्रोसॉफ्ट हाँ हाँ हाँ नहीं हाँ नहीं
Linkedin नहीं हाँ हाँ नहीं नहीं नहीं
याहू हाँ हाँ हाँ नहीं हाँ नहीं
सेब हाँ हाँ हाँ नहीं हाँ नहीं
एसएएमएल नहीं नहीं नहीं नहीं नहीं हाँ
ओआईडीसी हाँ हाँ हाँ नहीं हाँ हाँ

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

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

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

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

जेनेरिक ओआईडीसी प्रदाता

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

  • आईडी टोकन : बशर्ते कि 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,
    };
  }
});

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

निम्नलिखित उदाहरण कुछ आईपी पते श्रेणियों से साइन-इन को कैसे ब्लॉक करता है:

नोड.जे.एस

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

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

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

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

    नोड.जे.एस

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

उपयोगकर्ता संचालन के लिए reCAPTCHA एंटरप्राइज फैसले को ओवरराइड करें

निम्नलिखित उदाहरण दिखाता है कि समर्थित उपयोगकर्ता प्रवाह के लिए रीकैप्चा एंटरप्राइज फैसले को कैसे ओवरराइड किया जाए।

फायरबेस प्रमाणीकरण के साथ रीकैप्चा एंटरप्राइज को एकीकृत करने के बारे में अधिक जानने के लिए रीकैप्चा एंटरप्राइज को सक्षम करें देखें।

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

नोड.जे.एस

 const {
   auth,
 } = require("firebase-functions/v1");

exports.checkrecaptchaV1 = auth.user().beforeSignIn((userRecord, context) => {
 // Allow users with a specific email domain to sign in regardless of their recaptcha score.
 if (userRecord.email && userRecord.email.indexOf('@acme.com') === -1) {
   return {
     recaptchaActionOverride: 'ALLOW',
   };
 }

 // Allow users to sign in with recaptcha score greater than 0.5
 if (context.additionalUserInfo.recaptchaScore > 0.5) {
   return {
     recaptchaActionOverride: 'ALLOW',
   };
 }

 // Block all others.
 return {
   recaptchaActionOverride: 'BLOCK',
 };
});