Meet REST API के अनुरोधों की पुष्टि करें और उन्हें अनुमति दें

पुष्टि करने और अनुमति देने की प्रोसेस का इस्तेमाल, पहचान की पुष्टि करने और संसाधनों को ऐक्सेस करने के लिए किया जाता है. इस दस्तावेज़ में बताया गया है कि Google Meet REST API के अनुरोधों के लिए, पुष्टि करने और अनुमति देने की प्रोसेस कैसे काम करती है.

इस गाइड में, Meet REST API को ऐक्सेस करने के लिए, उपयोगकर्ता के Google क्रेडेंशियल के साथ OAuth 2.0 का इस्तेमाल करने का तरीका बताया गया है. उपयोगकर्ता के क्रेडेंशियल की मदद से पुष्टि करने और अनुमति देने पर, Meet ऐप्लिकेशन को उपयोगकर्ता का डेटा ऐक्सेस करने की अनुमति मिलती है. साथ ही, पुष्टि किए गए उपयोगकर्ता की ओर से कार्रवाइयां करने की अनुमति मिलती है. किसी उपयोगकर्ता की ओर से पुष्टि करने पर, ऐप्लिकेशन के पास वही अनुमतियां होती हैं जो उस उपयोगकर्ता के पास होती हैं. साथ ही, वह उन कार्रवाइयों को कर सकता है जो उस उपयोगकर्ता ने की हैं.

अहम शब्दावली

पुष्टि करने और अनुमति देने से जुड़े शब्दों की सूची यहां दी गई है:

पुष्टि करना

यह पक्का करने की प्रोसेस कि प्रिंसिपल, जो कोई उपयोगकर्ता हो सकता है

या उपयोगकर्ता की ओर से कार्रवाई करने वाला ऐप्लिकेशन, वही है जो वह होने का दावा करता है. Google Workspace ऐप्लिकेशन लिखते समय, आपको इन तरह के पुष्टि करने के तरीकों के बारे में पता होना चाहिए: उपयोगकर्ता की पुष्टि करना और ऐप्लिकेशन की पुष्टि करना. Meet REST API के लिए, सिर्फ़ उपयोगकर्ता की पुष्टि करने की सुविधा का इस्तेमाल किया जा सकता है.

अनुमति

प्रिंसिपल के पास, ऐक्सेस करने की अनुमतियां या "अधिकार"

डेटा को ऐक्सेस या उसमें बदलाव कर सकते हैं. अनुमति देने की प्रोसेस, आपके ऐप्लिकेशन में लिखे गए कोड के ज़रिए पूरी की जाती है. यह कोड, उपयोगकर्ता को बताता है कि ऐप्लिकेशन उसकी ओर से कार्रवाई करना चाहता है. अगर अनुमति मिलती है, तो यह कोड आपके ऐप्लिकेशन के यूनीक क्रेडेंशियल का इस्तेमाल करके, Google से ऐक्सेस टोकन हासिल करता है. इससे ऐप्लिकेशन को डेटा ऐक्सेस करने या कार्रवाइयां करने की अनुमति मिलती है.

REST API के स्कोप की ज़रूरी शर्तें पूरी करना

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

Meet REST API, OAuth 2.0 के इन स्कोप के साथ काम करता है:

स्कोप कोड ब्यौरा इस्तेमाल
https://www.googleapis.com/auth/meetings.space.settings Google Meet वाली सभी कॉल की सेटिंग देखना और उनमें बदलाव करना. संवेदनशील नहीं है
https://www.googleapis.com/auth/meetings.space.created ऐप्लिकेशन को, आपके ऐप्लिकेशन से बनाए गए मीटिंग स्पेस का मेटाडेटा बनाने, उसमें बदलाव करने, और उसे पढ़ने की अनुमति दें. संवेदनशील
https://www.googleapis.com/auth/meetings.space.readonly इससे ऐप्लिकेशन को, मीटिंग की उस जगह के बारे में मेटाडेटा पढ़ने की अनुमति मिलती है जिसे उपयोगकर्ता ऐक्सेस कर सकता है. संवेदनशील
https://www.googleapis.com/auth/drive.readonly ऐप्लिकेशन को Google Drive API से रिकॉर्डिंग और ट्रांसक्रिप्ट फ़ाइलें डाउनलोड करने की अनुमति दें. सभी देशों/इलाकों में उपलब्ध नहीं है

Meet से जुड़े OAuth 2.0 का यह स्कोप, Google Drive API के स्कोप की सूची में मौजूद है:

स्कोप कोड ब्यौरा इस्तेमाल
https://www.googleapis.com/auth/drive.meet.readonly Google Meet के ज़रिए बनाई गई या उसमें बदलाव की गई Drive फ़ाइलों को देखना. सभी देशों/इलाकों में उपलब्ध नहीं है

टेबल में मौजूद 'इस्तेमाल' कॉलम से पता चलता है कि हर स्कोप कितना संवेदनशील है. यह जानकारी, यहां दी गई परिभाषाओं के हिसाब से तय की जाती है:

  • कम संवेदनशील: इन स्कोप से, अनुमति के लिए सबसे कम ऐक्सेस मिलता है. साथ ही, इनके लिए सिर्फ़ ऐप्लिकेशन की बुनियादी पुष्टि की ज़रूरत होती है. ज़्यादा जानने के लिए, पुष्टि करने की ज़रूरी शर्तें देखें.

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

  • प्रतिबंधित: इन स्कोप से, Google के उपयोगकर्ता डेटा का ज़्यादातर हिस्सा ऐक्सेस किया जा सकता है. साथ ही, इनके लिए आपको प्रतिबंधित स्कोप की पुष्टि करने की प्रोसेस पूरी करनी होगी. ज़्यादा जानने के लिए, Google API सेवाओं की उपयोगकर्ता के डेटा से जुड़ी नीति और एपीआई के खास स्कोप के लिए अतिरिक्त ज़रूरी शर्तें देखें. अगर आपको सर्वर पर पाबंदी वाले स्कोप का डेटा सेव करना है या उसे ट्रांसफ़र करना है, तो आपको सुरक्षा जांच करानी होगी.

अगर आपके ऐप्लिकेशन को किसी अन्य Google API को ऐक्सेस करने की ज़रूरत है, तो उन स्कोप को भी जोड़ा जा सकता है. Google API के स्कोप के बारे में ज़्यादा जानने के लिए, OAuth 2.0 का इस्तेमाल करके, Google API को ऐक्सेस करना लेख पढ़ें.

उपयोगकर्ताओं और ऐप्लिकेशन की समीक्षा करने वालों को कौनसी जानकारी दिखेगी, यह तय करने के लिए OAuth के लिए सहमति लेने वाली स्क्रीन को कॉन्फ़िगर करना और स्कोप चुनना लेख पढ़ें.

OAuth 2.0 के कुछ स्कोप के बारे में ज़्यादा जानने के लिए, Google APIs के लिए OAuth 2.0 के स्कोप लेख पढ़ें.

पूरे डोमेन के लिए डेटा का ऐक्सेस देने की सुविधा का इस्तेमाल करके पुष्टि करना और अनुमति देना

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