पाबंदी वाले दायरे की पुष्टि

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

किसी एपीआई में पाबंदी वाले स्कोप लागू होने की संभावना, मुख्य रूप से इस बात पर निर्भर करती है कि आपके ऐप्लिकेशन में काम की सुविधा देने के लिए, किस तरह के ऐक्सेस की ज़रूरत है: सिर्फ़ पढ़ने का ऐक्सेस, सिर्फ़ लिखने का ऐक्सेस, पढ़ने और लिखने का ऐक्सेस वगैरह.

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

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

पाबंदी वाले स्कोप के बारे में जानकारी

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

स्कोप के इस्तेमाल के बारे में जानकारी

• उन स्कोप की समीक्षा करें जिनका इस्तेमाल आपका ऐप्लिकेशन करता है या जिनका इस्तेमाल आपको करना है. मौजूदा स्कोप के इस्तेमाल का पता लगाने के लिए, अनुमति के अनुरोधों के साथ भेजे गए किसी भी स्कोप के लिए, अपने ऐप्लिकेशन के सोर्स कोड की जांच करें.
• यह तय करें कि अनुरोध किया गया हर स्कोप, आपके ऐप्लिकेशन की सुविधा की ज़रूरी कार्रवाइयों के लिए ज़रूरी है और सुविधा देने के लिए, कम से कम विशेषाधिकार का इस्तेमाल किया जाता है. आम तौर पर, Google API के एंडपॉइंट के लिए, प्रॉडक्ट के Google Developer पेज पर रेफ़रंस दस्तावेज़ होता है. इसमें एंडपॉइंट या उसमें मौजूद खास प्रॉपर्टी को कॉल करने के लिए ज़रूरी स्कोप शामिल होता है. आपके ऐप्लिकेशन के कॉल किए गए एपीआई एंडपॉइंट के लिए, ऐक्सेस के ज़रूरी दायरों के बारे में ज़्यादा जानने के लिए, उन एंडपॉइंट के रेफ़रंस दस्तावेज़ पढ़ें. For example, for an app that only uses Gmail APIs to occasionally send emails on a user's behalf, don't request the scope that provides full access to the user's email data.
• Google API से मिलने वाले डेटा का इस्तेमाल, सिर्फ़ API की नीतियों के मुताबिक किया जाना चाहिए. साथ ही, इसका इस्तेमाल उसी तरह किया जाना चाहिए जिस तरह आपने अपने ऐप्लिकेशन की कार्रवाइयों और अपनी निजता नीति में अपने उपयोगकर्ताओं को बताया है.
• हर स्कोप के बारे में ज़्यादा जानने के लिए, एपीआई दस्तावेज़ देखें. इसमें, इसके संभावित sensitive or restricted स्टेटस के बारे में भी जानकारी मिलती है.
• के में, अपने ऐप्लिकेशन के इस्तेमाल किए गए सभी स्कोप की जानकारी दें. आपके बताए गए स्कोप को संवेदनशील या पाबंदी वाली कैटगरी में बांटा जाता है, ताकि पुष्टि से जुड़ी ज़रूरी शर्तों को हाइलाइट किया जा सके.
• अपने इंटिग्रेशन में इस्तेमाल किए गए डेटा से मैच करने वाला सबसे अच्छा स्कोप ढूंढें. साथ ही, इसके इस्तेमाल को समझें और फिर पुष्टि करें कि टेस्टिंग एनवायरमेंट में अब भी सब कुछ काम कर रहा है. इसके बाद, पुष्टि के लिए सबमिट करने की तैयारी करें.

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

अनुमति वाले ऐप्लिकेशन टाइप

कुछ खास तरह के ऐप्लिकेशन, हर प्रॉडक्ट के लिए सीमित दायरे को ऐक्सेस कर सकते हैं. आपको ऐप्लिकेशन के टाइप, प्रॉडक्ट के हिसाब से Google डेवलपर पेज पर मिल सकते हैं. उदाहरण के लिए, Gmail API की नीति.

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

सुरक्षा का आकलन

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

सुरक्षा आकलन को स्टैंडर्ड बनाने के लिए, हम App Defense Alliance और क्लाउड ऐप्लिकेशन सिक्योरिटी असेसमेंट फ़्रेमवर्क (सीएएसए) का इस्तेमाल करते हैं.

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

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

पुष्टि की प्रक्रिया के लिए तैयारी करने का तरीका

डेटा को ऐक्सेस करने का अनुरोध करने के लिए, Google API का इस्तेमाल करने वाले सभी ऐप्लिकेशन को ब्रैंड की पुष्टि करने के लिए, यह तरीका अपनाना होगा:

1. पुष्टि करें कि आपका ऐप्लिकेशन, पुष्टि से जुड़ी ज़रूरी शर्तों के अपवाद सेक्शन में दिए गए इस्तेमाल के उदाहरणों में से किसी भी उदाहरण में नहीं आता.
2. पक्का करें कि आपका ऐप्लिकेशन, उससे जुड़े एपीआई या प्रॉडक्ट की ब्रैंडिंग से जुड़ी ज़रूरी शर्तों को पूरा करता हो. उदाहरण के लिए, Google Sign-In के स्कोप के लिए ब्रैंडिंग के दिशा-निर्देश देखें.
3. Google Search Console में, अपने प्रोजेक्ट के अनुमति वाले डोमेन के मालिकाना हक की पुष्टि करें. उस Google खाते का इस्तेमाल करें जो आपके प्रोजेक्ट से जुड़ा है और जिसके पास, प्रोजेक्ट का मालिक या एडिटर ऐक्सेस है.
4. पक्का करें कि OAuth की सहमति वाली स्क्रीन पर, ब्रैंडिंग से जुड़ी सभी जानकारी सही हो. जैसे, ऐप्लिकेशन का नाम, सहायता के लिए ईमेल पता, होम पेज का यूआरआई, निजता नीति का यूआरआई वगैरह. इससे ऐप्लिकेशन की पहचान सही तरीके से ज़ाहिर होती है.

ऐप्लिकेशन के होम पेज से जुड़ी ज़रूरी शर्तें

पक्का करें कि आपका होम पेज इन ज़रूरी शर्तों को पूरा करता हो:

• आपका होम पेज सार्वजनिक तौर पर ऐक्सेस किया जा सकता हो. यह ज़रूरी नहीं है कि इसे सिर्फ़ आपकी साइट पर लॉग इन करने वाले उपयोगकर्ता ही ऐक्सेस कर पाएं.
• यह साफ़ तौर पर पता चलना चाहिए कि समीक्षा में शामिल ऐप्लिकेशन के लिए आपका होम पेज कितना काम का है.
• Google Play Store पर मौजूद आपके ऐप्लिकेशन की लिस्टिंग या उसके Facebook पेज के लिंक को, ऐप्लिकेशन के मान्य होम पेज नहीं माना जाता.

ऐप्लिकेशन की निजता नीति के लिंक से जुड़ी ज़रूरी शर्तें

पक्का करें कि आपके ऐप्लिकेशन की निजता नीति इन ज़रूरी शर्तों को पूरा करती हो:

• निजता नीति, उपयोगकर्ताओं को दिखनी चाहिए. साथ ही, यह नीति आपके ऐप्लिकेशन के होम पेज के डोमेन में होस्ट की जानी चाहिए. साथ ही, इसे की OAuth सहमति स्क्रीन से लिंक किया जाना चाहिए. ध्यान दें कि होम पेज पर, ऐप्लिकेशन के फ़ंक्शन के बारे में जानकारी के साथ-साथ, निजता नीति और सेवा की शर्तों के लिंक भी होने चाहिए. हालांकि, सेवा की शर्तें देना ज़रूरी नहीं है.
• निजता नीति में यह ज़ाहिर करना होगा कि आपका ऐप्लिकेशन, Google के उपयोगकर्ता के डेटा को कैसे ऐक्सेस, इस्तेमाल, और स्टोर करता है या शेयर करता है. The privacy policy must comply with the Google API Services User Data Policy and the Limited Use requirements for restricted scopes. आपको Google उपयोगकर्ता के डेटा का इस्तेमाल, अपनी पब्लिश की गई निजता नीति में बताए गए तरीकों तक ही सीमित रखना होगा.
• Review example cases of privacy policies that don't meet the Limited Use requirements.

अपने ऐप्लिकेशन की पुष्टि के लिए उसे सबमिट करने का तरीका

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

अगर आपका कोई OAuth क्लाइंट, प्रोडक्शन के लिए तैयार नहीं है, तो हमारा सुझाव है कि आप उसे उस प्रोजेक्ट से मिटा दें जिसके लिए पुष्टि का अनुरोध किया जा रहा है. ऐसा करने के लिए, पर जाएं.

पुष्टि के लिए सबमिट करने के लिए, यह तरीका अपनाएं:

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

5. इसके बाद, इनमें से चुनें डायलॉग बॉक्स में अपना प्रोजेक्ट चुनें. अगर आपको अपना प्रोजेक्ट नहीं मिल रहा है, लेकिन आपको अपना प्रोजेक्ट आईडी पता है, तो अपने ब्राउज़र में इस फ़ॉर्मैट में यूआरएल बनाएं:

   ?project=[PROJECT_ID]

   [PROJECT_ID] की जगह उस प्रोजेक्ट आईडी को डालें जिसका इस्तेमाल करना है.

6. ऐप्लिकेशन में बदलाव करें बटन चुनें.
7. OAuth सहमति वाली स्क्रीन के पेज पर ज़रूरी जानकारी डालें. इसके बाद, सेव करें और जारी रखें बटन को चुनें.
8. आपके ऐप्लिकेशन के अनुरोध किए गए सभी स्कोप का एलान करने के लिए, स्कोप जोड़ें या हटाएं बटन का इस्तेमाल करें. Google साइन इन के लिए ज़रूरी स्कोप का शुरुआती सेट, गैर-संवेदनशील स्कोप सेक्शन में पहले से भरा होता है. जोड़े गए स्कोप को गैर-संवेदनशील के तौर पर मार्क किया जाता है, sensitive, or restricted.
9. अपने ऐप्लिकेशन में मौजूद मिलती-जुलती सुविधाओं के लिए, काम के दस्तावेज़ों के ज़्यादा से ज़्यादा तीन लिंक दें.

10. अगले चरणों में, अपने ऐप्लिकेशन के बारे में मांगी गई कोई भी अतिरिक्त जानकारी दें.

    1. Ensure your app complies with the Additional requirements for specific API scopes, which includes undergoing an annual security assessment if your app accesses restricted scope Google users' data from or through a third-party server.
    2. Ensure your app is one of the allowed types specified in the Limited Use section of the Additional requirements for specific API scopes page.
    3. If your app is a task automation platform, your demonstration video must showcase how multiple API workflows are created and automated, and in which directions user data flows.

    4. Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.

       1. Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
       2. Show that the OAuth consent screen correctly displays the App Name.
       3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
       4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive and restricted scope that you request.
       5. If you use multiple clients, and therefore have multiple OAuth client IDs, show how the data is accessed on each OAuth client.
    5. Select your permitted application type from the "What features will you use?" list.
    6. Describe how you will use the restricted scopes in your app and why more limited scopes aren't sufficient.
11. अगर आपके दिए गए ऐप्लिकेशन कॉन्फ़िगरेशन की पुष्टि ज़रूरी है, तो आपके पास पुष्टि के लिए ऐप्लिकेशन को सबमिट करने का विकल्प है. ज़रूरी फ़ील्ड भरें. इसके बाद, पुष्टि की प्रोसेस शुरू करने के लिए सबमिट करें पर क्लिक करें.

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

पुष्टि की ज़रूरी शर्तों से जुड़े अपवाद

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

निजी इस्तेमाल के लिए

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

ध्यान दें: उपयोगकर्ताओं की संख्या की सीमा से, उन Google खातों की संख्या पर पाबंदी लगती है जो आपके ऐसे ऐप्लिकेशन को ऐक्सेस कर सकते हैं जिसकी पुष्टि नहीं हुई है.

डेवलपमेंट, टेस्टिंग या स्टैजिंग टीयर में इस्तेमाल किए जाने वाले प्रोजेक्ट

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

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

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

पहली इमेज 1. टेस्टर के लिए चेतावनी वाली स्क्रीन

सिर्फ़ सेवा के मालिकाना हक वाला डेटा

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

सेवा खाते क्या होते हैं, यह समझने के लिए, Google Cloud के दस्तावेज़ में सेवा खाते देखें. सेवा खाते का इस्तेमाल करने का तरीका जानने के लिए, सर्वर से सर्वर के लिए OAuth 2.0 का इस्तेमाल करना लेख देखें.

केवल आंतरि‍क उपयोग के लि‍ए

इसका मतलब है कि इस ऐप्लिकेशन का इस्तेमाल सिर्फ़ आपके Google Workspace या Cloud Identity के संगठन के लोग कर सकते हैं. प्रोजेक्ट पर संगठन का मालिकाना हक होना चाहिए. साथ ही, उसकी OAuth सहमति स्क्रीन को इंटरनल उपयोगकर्ता टाइप के लिए कॉन्फ़िगर करना होगा. इस मामले में, आपके ऐप्लिकेशन को संगठन के एडमिन से अनुमति लेनी पड़ सकती है. ज़्यादा जानकारी के लिए, Google Workspace के लिए अन्य बातें लेख पढ़ें.

• सार्वजनिक और संगठन के लिए बनाए गए ऐप्लिकेशन के बारे में ज़्यादा जानें.
• अपने ऐप्लिकेशन को 'सिर्फ़ संगठन के लिए' के तौर पर मार्क करने का तरीका जानने के लिए, अक्सर पूछे जाने वाले सवालों के जवाब देखें मैं अपने ऐप्लिकेशन को 'सिर्फ़ संगठन के लिए' के तौर पर कैसे मार्क करूं?

पूरे डोमेन के लिए इंस्टॉल करना

अगर आपको अपने ऐप्लिकेशन को सिर्फ़ Google Workspace या Cloud Identity के किसी संगठन के उपयोगकर्ताओं को टारगेट करना है और हमेशा डोमेन के सभी डिवाइसों पर इंस्टॉल करने की सुविधा का इस्तेमाल करना है, तो आपके ऐप्लिकेशन को पुष्टि करने की ज़रूरत नहीं होगी. ऐसा इसलिए है, क्योंकि डोमेन के लिए एक ही ऐप्लिकेशन इंस्टॉल करने पर, डोमेन एडमिन को तीसरे पक्ष और इंटरनल ऐप्लिकेशन को आपके उपयोगकर्ताओं के डेटा का ऐक्सेस देने की अनुमति मिलती है. संगठन के एडमिन ही अपने डोमेन में ऐप्लिकेशन का इस्तेमाल करने के लिए, ऐप्लिकेशन को अनुमति वाली सूची में जोड़ सकते हैं.

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