Google ने ऐप्लिकेशन के ऐक्सेस को कंट्रोल करने वाली सेटिंग लॉन्च की हैं. इनकी मदद से, Google Workspace for Education के एडमिन यह कंट्रोल कर सकते हैं कि तीसरे पक्ष के ऐप्लिकेशन, उनके संगठन का Google डेटा कैसे ऐक्सेस करें. यह सेटिंग तब लागू होती है, जब उपयोगकर्ता अपने Google Workspace for Education खातों से साइन इन करते हैं. तीसरे पक्ष के ऐप्लिकेशन के डेवलपर को कोई कार्रवाई करने की ज़रूरत नहीं है. हालांकि, यहां कुछ ऐसे सबसे सही तरीके दिए गए हैं जो अन्य डेवलपर के लिए मददगार साबित हुए हैं.
इंक्रीमेंटल OAuth का इस्तेमाल करना
इंक्रीमेंटल ऑथराइज़ेशन का इस्तेमाल करके, शुरुआत में सिर्फ़ उन दायरों के लिए अनुरोध किया जा सकता है जिनकी ज़रूरत आपके ऐप्लिकेशन को शुरू करने के लिए होती है. इसके बाद, नई अनुमतियों की ज़रूरत पड़ने पर, अतिरिक्त दायरों के लिए अनुरोध किया जा सकता है. इसके बाद, ऐप्लिकेशन का कॉन्टेक्स्ट, उपयोगकर्ता को अनुरोध की वजह बताता है.
साइन इन करने पर, आपका ऐप्लिकेशन बुनियादी दायरों के लिए अनुरोध करता है. जैसे, साइन-इन स्कोप प्रोफ़ाइल और अन्य शुरुआती दायरे जिनकी ज़रूरत आपके ऐप्लिकेशन को काम करने के लिए होती है. बाद में, जब उपयोगकर्ता कोई ऐसी कार्रवाई करना चाहता है जिसके लिए अतिरिक्त दायरों की ज़रूरत होती है, तो आपका ऐप्लिकेशन उन अतिरिक्त दायरों के लिए अनुरोध करता है. इसके बाद, उपयोगकर्ता सहमति वाली स्क्रीन से सिर्फ़ नए दायरों को अनुमति देता है.
Google Classroom ऐड-ऑन बनाते समय, आपको Google Workspace Marketplace दिशा-निर्देशों का पालन करना चाहिए. इसके तहत, आपको OAuth के उन सभी दायरों की पूरी सूची देनी होगी जिनकी ज़रूरत आपके ऐप्लिकेशन को है. यह ज़रूरी है, ताकि एडमिन को यह पता चल सके कि डोमेन के किसी उपयोगकर्ता से किन दायरों के लिए सहमति देने के लिए कहा गया है.
पक्का करें कि सभी ऐप्लिकेशन की OAuth से पुष्टि हो गई हो
Google API को ऐक्सेस करने वाले सभी ऐप्लिकेशन को यह पुष्टि करनी होगी कि वे अपनी पहचान और इरादे को सटीक तरीके से दिखाते हैं. यह पुष्टि, Google की API सेवाओं के उपयोगकर्ता डेटा की नीति के मुताबिक होनी चाहिए. अगर आपके पास Google API का इस्तेमाल करने वाले एक से ज़्यादा ऐप्लिकेशन हैं, तो पक्का करें कि हर ऐप्लिकेशन की पुष्टि हो गई हो. एडमिन को, पुष्टि किए गए आपके ब्रैंड से जुड़े सभी OAuth क्लाइंट आईडी दिख सकते हैं. एडमिन को गलत OAuth क्लाइंट आईडी कॉन्फ़िगर करने से रोकने के लिए, टेस्ट करने और प्रोडक्शन के लिए अलग-अलग Google Cloud प्रोजेक्ट का इस्तेमाल करें. साथ ही, उन सभी OAuth क्लाइंट आईडी को मिटा दें जिनका इस्तेमाल नहीं किया जा रहा है.
OAuth API की पुष्टि एक ऐसी प्रोसेस है जिसका इस्तेमाल Google Cloud Platform यह पक्का करने के लिए करता है कि संवेदनशील या प्रतिबंधित दायरों का अनुरोध करने वाले ऐप्लिकेशन सुरक्षित हैं और नीति के मुताबिक हैं. पुष्टि की प्रोसेस, Google Cloud के उपयोगकर्ताओं और डेटा को गलत हाथों में जाने से बचाने में मदद करती है.
संवेदनशील या प्रतिबंधित दायरों का अनुरोध करने वाले ऐप्लिकेशन को, Google की API सेवाओं के उपयोगकर्ता के डेटा से जुड़ी नीति का पालन करना होगा. इस नीति के तहत, ऐप्लिकेशन को उपयोगकर्ता के डेटा को सुरक्षित रखना होगा. साथ ही, डेटा का इस्तेमाल सिर्फ़ उन कामों के लिए करना होगा जिनके लिए उपयोगकर्ता ने अनुमति दी है. ऐप्लिकेशन को, Google Cloud की सुरक्षा से जुड़ी ज़रूरी शर्तों को पूरा करने की पुष्टि करने के लिए, सुरक्षा का आकलन भी कराना पड़ सकता है.
ध्यान दें कि OAuth API की पुष्टि की प्रोसेस को पूरा होने में कई हफ़्ते लग सकते हैं. आपके ऐप्लिकेशन की पुष्टि हो जाने के बाद, संवेदनशील या प्रतिबंधित उन दायरों के लिए अनुरोध किया जा सकता है जिनकी आपको ज़रूरत है.
ज़्यादा जानकारी के लिए, OAuth API की पुष्टि से जुड़े अक्सर पूछे जाने वाले सवाल देखें.
एक से ज़्यादा OAuth क्लाइंट आईडी मैनेज करना
किसी Google Cloud प्रोजेक्ट के पास एक से ज़्यादा OAuth क्लाइंट आईडी हो सकते हैं. ऐसे में, डोमेन के एडमिन को आपके ऐक्सेस को कई बार कॉन्फ़िगर करना पड़ सकता है.
पक्का करें कि OAuth क्लाइंट आईडी सही हों
यह जानने के लिए कि Google OAuth के साथ इंटिग्रेट करने के लिए किन OAuth क्लाइंट आईडी का इस्तेमाल किया जा रहा है, अपनी डेवलपमेंट टीम से संपर्क करें. एडमिन को यह समझने में मदद करने के लिए कि किन OAuth क्लाइंट आईडी को कॉन्फ़िगर करना है, टेस्ट करने और प्रोडक्शन के लिए दो अलग-अलग Google Cloud प्रोजेक्ट का इस्तेमाल करें. अपने प्रोडक्शन प्रोजेक्ट से, बंद हो चुके या पुराने क्लाइंट आईडी मिटा दें.
CSV फ़ाइल अपलोड करें
अगर आपके पास एक से ज़्यादा क्लाइंट आईडी हैं, तो हमारा सुझाव है कि आप CSV फ़ाइल अपलोड करने के विकल्प का इस्तेमाल करें. इससे एडमिन आपके सभी ऐप्लिकेशन को तेज़ी से कॉन्फ़िगर कर पाएंगे.
ये फ़ील्ड हैं:
| फ़ील्ड | ज़रूरी है | नोट |
|---|---|---|
| ऐप्लिकेशन का नाम | नहीं | ऐप्लिकेशन का नाम डालें. CSV फ़ाइल में ऐप्लिकेशन के नाम में किए गए बदलाव, Admin console में अपडेट नहीं होते. |
| टाइप | हां | इनमें से कोई एक: वेब ऐप्लिकेशन, Android या iOS. |
| सरकारी आईडी | हां | वेब ऐप्लिकेशन के लिए, ऐप्लिकेशन को जारी किया गया OAuth क्लाइंट आईडी डालें. Android और iOS ऐप्लिकेशन के लिए, OAuth क्लाइंट आईडी या पैकेज या बंडल आईडी डालें. इस आईडी का इस्तेमाल, ऐप्लिकेशन Google Play या Apple App Store में करता है. |
| संगठन इकाई | हां | इसे ग्राहक को भरना होगा. अपने पूरे डोमेन पर ऐप्लिकेशन के ऐक्सेस की सेटिंग लागू करने के लिए, फ़ॉरवर्ड स्लैश ('/') डालें. खास संगठन इकाइयों पर ऐक्सेस की सेटिंग लागू करने के लिए, स्प्रेडशीट में हर संगठन इकाई के लिए एक पंक्ति जोड़ें. साथ ही, ऐप्लिकेशन का नाम, टाइप, और आईडी दोहराएं. उदाहरण के लिए, '/org_unit_1/sub_unit_1'. |
| ऐक्सेस | हां | इनमें से कोई एक: भरोसेमंद, ब्लॉक किया गया या सीमित. |
OAuth से जुड़ी गड़बड़ियां
एडमिन के लिए नए कंट्रोल के साथ, गड़बड़ी के दो मैसेज लॉन्च किए गए हैं.
- गड़बड़ी 400: access_not_configured - यह गड़बड़ी तब दिखती है, जब OAuth कनेक्शन को अस्वीकार कर दिया जाता है, क्योंकि आपके ऐप्लिकेशन को कॉन्फ़िगर नहीं किया गया है.
- गड़बड़ी 400: admin_policy_enforced - यह गड़बड़ी तब दिखती है, जब OAuth कनेक्शन को अस्वीकार कर दिया जाता है, क्योंकि एडमिन ने आपके ऐप्लिकेशन को ब्लॉक कर दिया है.
18 साल से कम उम्र के उपयोगकर्ता
एडमिन, 18 साल से कम उम्र के उपयोगकर्ताओं के लिए, तीसरे पक्ष के उन ऐप्लिकेशन का ऐक्सेस मैनेज कर सकते हैं जिन्हें कॉन्फ़िगर नहीं किया गया है. अगर किसी उपयोगकर्ता को "ऐक्सेस ब्लॉक किया गया: आपके संस्थान के एडमिन को [ऐप्लिकेशन का नाम] की समीक्षा करनी होगी" गड़बड़ी दिखती है, तो उसे गड़बड़ी के मैसेज में जाकर ऐक्सेस का अनुरोध करना होगा. इससे, एडमिन तीसरे पक्ष के ऐप्लिकेशन की समीक्षा कर पाएगा. एडमिन यह तय कर सकते हैं कि तीसरे पक्ष के ऐप्लिकेशन को अनुमति देनी है या ब्लॉक करना है.