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

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

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

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

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

---

प्रतिबंधित स्कोप के बारे में जानकारी

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

स्कोप के इस्तेमाल को समझना

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

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

---

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

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

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

---

सुरक्षा जांच

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

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

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

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

---

पुष्टि की प्रक्रिया शुरू करने से पहले की जाने वाली तैयारी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   https://console.developers.google.com/auth/branding?project=[PROJECT_ID]
   

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

6. ब्रैंडिंग पेज पर, अपने ऐप्लिकेशन की ब्रैंडिंग की जानकारी दें. इसमें ऐप्लिकेशन का नाम, लोगो, डेवलपर की संपर्क जानकारी, और काम के लिंक शामिल हैं. आपके किए गए सभी बदलाव, ड्राफ़्ट ब्रैंडिंग के तौर पर सेव हो जाते हैं.

7. समीक्षा की प्रोसेस शुरू करने के लिए, ब्रैंडिंग की पुष्टि करें बटन पर क्लिक करें. आम तौर पर, अपने-आप होने वाली समीक्षा कुछ मिनटों में पूरी हो जाती है.

8. आकलन पूरा होने के बाद, स्टेटस देखें. अगर बदलावों को मंज़ूरी मिल जाती है, तो स्टेटस बदलकर पब्लिश करने के लिए तैयार हो जाता है. अगर अपने-आप होने वाली पुष्टि की सुविधा काम नहीं करती है, तो आपको पता लगाई गई समस्याएं दिखेंगी. इसके बाद, उन्हें ठीक किया जा सकता है या मैन्युअल समीक्षा का अनुरोध किया जा सकता है.

9. नई ब्रैंडिंग को लाइव करने के लिए, ब्रैंडिंग पब्लिश करें बटन पर क्लिक करें.

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

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

12. अपने ऐप्लिकेशन में मौजूद सुविधाओं से जुड़े दस्तावेज़ों के ज़्यादा से ज़्यादा तीन लिंक दें.

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

    1. पक्का करें कि आपका ऐप्लिकेशन, एपीआई के कुछ खास स्कोप के लिए तय की गई अतिरिक्त शर्तों का पालन करता हो. इनमें हर साल सुरक्षा से जुड़ी जांच कराना भी शामिल है. ऐसा तब करना ज़रूरी है, जब आपका ऐप्लिकेशन किसी तीसरे पक्ष के सर्वर से या उसके ज़रिए, Google उपयोगकर्ताओं के सीमित स्कोप वाले डेटा को ऐक्सेस करता हो.
    2. पक्का करें कि आपका ऐप्लिकेशन, एपीआई के कुछ खास स्कोप के लिए अन्य ज़रूरी शर्तें पेज के सीमित इस्तेमाल सेक्शन में बताई गई अनुमति वाली कैटगरी में से एक हो.
    3. अगर आपका ऐप्लिकेशन, टास्क ऑटोमेशन प्लैटफ़ॉर्म है, तो आपको डेमो वीडियो में यह दिखाना होगा कि कई एपीआई वर्कफ़्लो कैसे बनाए जाते हैं और उन्हें कैसे ऑटोमेट किया जाता है. साथ ही, यह भी दिखाना होगा कि उपयोगकर्ता का डेटा किस दिशा में फ़्लो होता है.
    4. एक ऐसा वीडियो तैयार करें जिसमें पूरी जानकारी दी गई हो कि कोई उपयोगकर्ता, अनुरोध किए गए स्कोप को कैसे ऐक्सेस करता है और उनकी अनुमति कैसे देता है. साथ ही, ऐप्लिकेशन में अनुमति दिए गए संवेदनशील और प्रतिबंधित स्कोप के इस्तेमाल के बारे में पूरी जानकारी दी गई हो. वीडियो को YouTube Studio पर अपलोड करें और किसको दिखे को सबके लिए मौजूद नहीं के तौर पर सेट करें. आपको YouTube लिंक फ़ील्ड में, डेमो वीडियो का लिंक देना होगा.
       1. OAuth के इस्तेमाल की अनुमति देने की प्रोसेस को अंग्रेज़ी में दिखाएं. इसमें सहमति देने का फ़्लो और अगर Google साइन-इन का इस्तेमाल किया जाता है, तो साइन-इन का फ़्लो शामिल है.
       2. यह दिखाएं कि OAuth के लिए सहमति देने वाली स्क्रीन पर, ऐप्लिकेशन का नाम सही तरीके से दिख रहा है.
       3. यह दिखाएं कि OAuth की सहमति वाली स्क्रीन के ब्राउज़र पता बार में, आपके ऐप्लिकेशन का OAuth क्लाइंट आईडी सही तरीके से शामिल है.
       4. यह दिखाने के लिए कि डेटा का इस्तेमाल कैसे किया जाएगा, उस सुविधा के बारे में बताएं जो संवेदनशील और प्रतिबंधित दायरे में आने वाले हर उस स्कोप से चालू होती है जिसके लिए आपने अनुरोध किया है.
       5. अगर एक से ज़्यादा क्लाइंट इस्तेमाल किए जाते हैं और इसलिए आपके पास कई OAuth क्लाइंट आईडी हैं, तो यह दिखाएं कि हर OAuth क्लाइंट पर डेटा को कैसे ऐक्सेस किया जाता है.
    5. "आपको किन सुविधाओं का इस्तेमाल करना है?" सूची से, अनुमति वाले ऐप्लिकेशन टाइप को चुनें.
    6. यह बताएं कि आपके ऐप्लिकेशन में, प्रतिबंधित दायरों का इस्तेमाल कैसे किया जाएगा. साथ ही, यह भी बताएं कि सीमित दायरे आपके लिए काफ़ी क्यों नहीं हैं.

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

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

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

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

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

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

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

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

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

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

सेवा खातों के बारे में जानने के लिए, Google Cloud के दस्तावेज़ में सेवा खाते देखें. सेवा खाते का इस्तेमाल करने के तरीके के बारे में जानने के लिए, सर्वर से सर्वर ऐप्लिकेशन के लिए OAuth 2.0 का इस्तेमाल करना लेख पढ़ें.

सिर्फ़ अंदरूनी इस्तेमाल के लिए

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

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

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

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

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